Certificates
Access to this application is managed by Guidewire Hub. For details, see Access Cloud Platform apps and services.
Cloud Platform supports mutual Transport Layer Security (mTLS) authentication. To use it, you must provide SSL certificates. In connections authenticated by mTLS, both sides of the connection must perform an mTLS handshake. In this process, both sides check each other's TLS certificates, confirm authenticity, validate expiration dates, and ensure certificates aren't revoked.
When you upload security certificates, all data transferred between InsuranceSuite applications and third-party servers in HTTPS connections is encrypted, private, and can't be corrupted or intercepted. You don't need to redeploy an application after uploading certificates.
Cloud Platform accepts the two following types of certificates:
-
CA certificate
Certificate issued by a certificate authority (CA), an organization that confirms the identity of the certificate holder. CA certificates are used to issue other certificates. There are two types of CA certificates:
- Root CA certificates that are self-signed.
- Intermediate CA certificates that are issued by other CA certificates.
You can upload a CA certificate as a part of TrustStore configuration.
-
Leaf certificate
Certificate that can be issued by the CA to a server, a domain, or a website. Leaf certificate confirms the identity of the certificate holder. It can't be used to create other certificates.
You can upload a leaf certificate as a part of KeyStore configuration.
Guidewire doesn't provide Client certificates and Client private keys. You must generate them using, for example, OpenSSL.
Certificate chains
Certificate chain is a combination of leaf, intermediate CA, and root CA certificates issued to a server or a client. Chains are stored in PEM container files. While all certificates inside a chain are indirectly related and help identify one entity, there's no direct link between the leaf certificate and the root CA certificate.
You can't upload certificate chains.
If you have a PEM file containing a chain of certificates applicable for inbound and outbound connections, you must first create separate PEM files and validate their content. For details, see Extract certificates from a certificate chain.
Inside a PEM file, certificates are separated by -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- blocks of text.
A container file might also contain a private key, separated by -----BEGIN RSA PRIVATE KEY----- and -----END RSA PRIVATE KEY----- blocks. Otherwise, look for it in the file containing the certificate chain.
Inbound connections
Inbound connections come from the outside of your network.
To configure inbound connections, you must provide a CA certificate that signs the client's certificate as a part of the TrustStore configuration. You can use an intermediate CA or a private CA certificate. For details, see Create an mTLS configuration.
Example
A third-party server initiates a connection and sends an HTTPS request to the InsuranceSuite application. The application accepts and processes the request if the connection can be trusted.
For inbound traffic, InsuranceSuite provides a publicly trusted server certificate that is frequently rotated. Inbound clients must be configured to trust this certificate. In most cases, Guidewire recommends that clients use a default trust store that is already configured to trust this server certificate. Otherwise, Guidewire recommends trusting our root CA certificate, since the root certificate has a longer expiration time and will be used to issue future certificates.
After the client initiates the connection, InsuranceSuite identifies the server by checking its certificate. You can later reuse the same CA certificate to generate leaf certificates for additional servers that will send a message to the application.
Outbound connections
Outbound connections come from the inside of your network.
When configuring outbound connections, you need to upload three files that will make third-party servers and InsuranceSuite applications trust each other:
- An application domain’s public certificate.
- An application domain’s private key linked to the public certificate.
- Third-party server’s root CA certificate.
For details, see Create an mTLS configuration.
Example
InsuranceSuite application initiates a connection to the remote database to fetch external data needed to process a policy.
InsuranceSuite must initiate HTTP connections when contacting endpoints secured by mTLS. When a client initiates a HTTP connection at the application level, then the network layer of the Cloud Platform converts the traffic to HTTPS using the configured certificates.
When initiating the connection, InsuranceSuite shares the client's public certificate, which includes the public key. The private key isn't shared with the third-party server but is required to confirm the client's identity.
There are two ways of obtaining a public certificate for a new client domain:
- Generating a self-signed certificate using OpenSSL.
- Submitting a certificate signing request (CSR) to a trusted CA.
When creating or ordering a certificate, keep in mind that the private key size must exceed 2048 bits.
The public and CA certificates required for outbound connections are not part of the same certificate chain. The public certificate identifies the client and doesn't need to be signed by the CA that issued the third-party server's intermediate CA certificate.
Only the third-party server's CA certificate will let InsuranceSuite communicate with the third-party server.
Third-party server certificates
If the third-party server is publicly accessible, you can retrieve its certificate chain using OpenSSL, including the CA certificate. This example command retrieves the certificates from a server and saves the output in certificates.pem:
echo | openssl s_client -showcerts -connect <host>:<port> > certificates.pem
The output file will also contain information about the issuer (CA) and the subject of each certificate.