Both LightWave Server and LightWave Client support network connections protected by Transport Layer Security (TLS).
- Both products support TLS connections when connecting to the product Consoles.
- LightWave Server supports inbound TLS connections when connecting to the REST service endpoints it makes available.
- LightWave Client supports outbound TLS connections to remote REST service endpoints.
When making connections to the product Consoles or REST service endpoints, using HTTPS in the endpoint URL automatically creates a TLS connection.
In order to establish a TLS connection with any server, a Server Certificate is required. This article explains what these certificates are and how they are used in the LightWave products.
What is a Server Certificate?
In the TLS world a Server Certificate, also known as a Public key certificate, is a file containing identity information needed to establish a TLS connection. The identity information is stored in individual data fields in a file using the X509 standard. The X509 standard is a flexible storage format which may contain any number of fields used to store the identity information, and there are a number of different types of certificates used for different purposes. Certificates may be stored as binary files known as DER format, or as text files known as PEM format.
A Server Certificate is always accompanied by a Private Key. The Private Key is a component of Public-key or asymmetric cryptography. An in-depth explanation of public-key cryptography is beyond the scope of this article, but to summarize:
- For each private key, there is a public key, which can be derived from the private key.
- Data encrypted with the private key can only be decrypted with the public key.
- Data encrypted with the public key can only be decrypted with the private key.
As a result:
- Two parties may have an encrypted message exchange when one party has a private key and the other has the associated public key.
- This exchange may occur without either party revealing the "secret" to encrypting or decrypting the exchange. Both parties have different keys.
- The private key holder must keep the private key confidential but may distribute the public key to anyone.
- This is different than symmetric cryptography, where both parties must know the same secret in order for the encrypted exchange to occur, i.e, one party must reveal the secret to the other, and both parties must keep the secret confidential.
When a server certificate is created, the public key is embedded in the Server Certificate. This comes into play during the TLS handshake.
How is the Certificate Used in the TLS Handshake?
During the TLS handshake process, the server side of the connection sends its Server Certificate to the client. The client then begins the certificate verification process, which checks the following attributes of the certificate (not necessarily in this order):
- Has the certificate been tampered with - check the certificate's digital signature to ensure that it has not been altered since it was signed.
- Is the certificate valid - check the certificate's expiration date.
- Has the connection been established to the intended host - check that the host name used in the URL to connect to the server is listed in the certificate's common name or in the certificate's list of host alternative names.
- Was the certificate signed by a Certificate Authority that is trusted.
If any of these tests fail during the verification process, the TLS handshake fails, and the connection is rejected. Once the certificate is validated, the public key in the certificate is used to encrypt the remainder of the handshake process, which includes establishing the cryptographic algorithms that will be sued for the connection, and the secrets that will be used with those algorithms. Note that because public-key cryptography is used, the server keeps the private key confidential, but may supply the public key to any entity that connects to the server by embedding it in the certificate. This allows a client and server to exchange encrypted messages without requiring both sides to share a pre-determined secret.
Where do Certificates Come From?
In the previous section, the final check in the TLS handshake process determines if the certificate has been signed by a trusted Certificate Authority (CA). Because X509 and public key cryptography are well known standards, anyone can create and sign X509 certificates. But if the certificate has not been signed by an entity that the client trusts, none of the previous checks can be trusted. This trust relationship is the foundation public key certificates. If the certificate was not signed by a trusted entity, the information in the certificate and the signature itself cannot be trusted.
Certificates are obtained by creating a Certificate Signing Request (CSR) and submitting it to a Certificate Authority for signing. The CSR is an unsigned X509 Server Certificate, containing all of the information describing the requesting entity. The CA will verify that the information in the certificate is valid, and that the submitter has the authority to request the certificate. When satisfied, the CA will sign the certificate and return it to the requester. LightWave products have the ability to generate a CSR and then install the associated signed certificate when received from the CA. LightWave products can also import a signed certificate that was generated using an external CSR process.
Who do you Trust?
In order to solve the trust issue, the Root Certificate Authority system was created, and a number of trusted Root Certificate Authorities were established by the industry. Initially the number of Root CAs was small but as of this writing there are well over 100 Root CAs. If a Server Certificate is signed by a Root CA, the client has some assurance that the certificate was not signed by "just anybody".
It's important to note that though Root CAs are considered trusted, they are not blindly trusted. Every browser and REST client framework, including LightWave Client, includes a list of Root CAs that it trusts. During the certificate verification process, this list of trusted Root CA certificates is checked to make sure the server certificate was signed by one of the Root CAs in the list. In LightWave Client, this list is found in the CAROOT file which is periodically updated with the latest list of Root CAs and included in each release.
What are Intermediate Certificates?
While there are currently over 100 Root CAs, there are millions of certificates and entities who need them signed. This need led to the creation of intermediate certificate authorities that have the ability to sign certificates that have the same trust level as a Root CA.
How can these intermediate CAs be trusted? The certificates used by Intermittent CAs to sign server certificates, are themselves signed by Root CAs. This establishes a chain of trust, with the Root CA as the trust anchor.
There can be more than one intermediate CA, and when intermediate CAs are in the trust chain, this changes the certificate verification process that occurs during the TLS handshake. During the handshake, the server will present the Server Certificate and any intermediate CA certificates that are needed to establish the chain of trust. The client will check the certificate chain, verifying that each certificate was signed by the next CA in the chain, and that the final CA is a Root CA that is present in the list of trusted Root CAs.
Many enterprise level businesses establish their own internal Intermediate CAs. This allows them to manage the provisioning of certificates they need without the delays and cost of involving an outside certificate authority.
What are Self Signed Certificates?
In order to establish a TLS connection, a signed server certificate is necessary, but there can be costs and administrative delays associated with obtaining a server certificate from a root or intermediate CA. Because X509 and public key cryptography is a standard, anyone can create and sign Server Certificates. Server Certificates that are not signed by intermediate or root CAs are known as self-signed certificates. Although they are not globally trusted, they may be locally trusted and appropriate for use in development & test environments. In order to be used effectively, the client application must be configured to bypass the trust chain check, or the certificate of the local CA that signed the service certificate must be added to the list of trusted root authorities. In LightWave Client, using the CLIENT process –cert-no-verify option or adding the CA certificate to the CAROOT file will accomplish this. Note that self-signed certificates should never be used in a production application.
Bringing it All Together
In order to use Server Certificates with LightWave products, follow these steps:
- Determine whether or not a trusted certificate or self-signed certificate is needed. If a self-signed certificate is sufficient, use the option to create a Certificate Signing Request (CSR) and select the option to create a self-signed certificate. The certificate will be created, signed, and installed.
- If a trusted certificate is required, determine if the CSR will be generated from the LightWave Console, or through a third-party process. If a LightWave CSR will be used, created the CSR from the LightWave Console and submit it to a certificate authority. Note that when creating the CSR, the host name used to establish the TLS connection must match the host name in the Common Name field, or one of the hosts in the list of alternate host names. The host name check is part of the certificate verification process, and this is true whether the CSR is created using the LightWave Console or a third-party CSR process.
- When the certificate is received from the CA, install it using the LightWave Console or the LWSCOM IMPORT CERTIFICATE command.
- If any intermediate certificates are supplied by the CA, they must be installed as intermediate certificates. This can be done in the LightWave Console Intermediate Certificate section, or using the CHAIN option with the LWSCOM IMPORT CERTIFICATE command.
Further information on managing certificates can be found in the LightWave documentation: