LibraryLink ToToggle FramesPrintFeedback

Special Requirements on HTTPS Certificates

The HTTPS specification mandates that HTTPS clients should be capable of verifying the identity of the server. This can potentially affect how you generate your X.509 certificates. The mechanism for verifying the server identity depends on the type of client. Some clients might verify the server identity by accepting only those server certificates signed by a particular trusted CA. In addition, clients cosuld also inspect the contents of a server certificate and accept only the certificates that satisfy specific constraints.

In the absence of an application-specific mechanism, the HTTPS specification defines a generic mechanism, known as the HTTPS URL integrity check, for verifying the server identity. For example, this is the standard mechanism used by Web browsers.

The basic idea of the URL integrity check is that the server certificate’s identity must match the server host name. This integrity check has an important impact on how you generate X.509 certificates for HTTPS: the certificate identity (usually the certificate subject DN’s common name) must match the host name on which the HTTPS server is to be deployed.

The URL integrity check is designed to prevent man-in-the-middle attacks.

The HTTPS URL integrity check is specified by RFC 2818, published by the Internet Engineering Task Force (IETF):

http://www.ietf.org/rfc/rfc2818.txt

The certificate identity used in the URL integrity check can be specified in one of the following ways:

The usual way to specify the certificate identity (for the purpose of the URL integrity check) is to set the Common Name (CN) in the subject DN of the certificate.

For example, if clients are meant to connect to the following secure URL:

https://www.iona.com/secure

The server certificate could have a subject DN like the following:

C=IE,ST=Co. Dublin,L=Dublin,O=IONA Technologies PLC,
OU=System,CN=www.iona.com

Where the CN has been set to the host name, www.iona.com. For details of how to set the subject DN in a new certificate, see Use the CA to Create Signed Certificates in a Java Keystore and Use the CA to Create Signed Certificates in a Java Keystore .

Using the subject DN’s Common Name for the certificate identity suffers from the disadvantage that only one host name can be specified at a time. If you deploy a certificate on a multi-homed host, however, you might find it is practical to allow the certificate to be used with any of the multi-homed host names. In this case, it is necessary to define a certificate with multiple, alternative identities and this is only possible using the subjectAltName certificate extension.

For example, if you have a multi-homed host that supports connections to either of the following host names:

www.iona.com
fusesource.com

You could define a subjectAltName that explicitly lists both of these DNS host names. If you generate your certificates using the openssl utility, you would need to edit the relevant line of your openssl.cnf configuration file to specify the value of the subjectAltName extension, as follows:

subjectAltName=DNS:www.iona.com,DNS:fusesource.com

Where the HTTPS protocol will match either of the DNS host names listed in the subjectAltName (the subjectAltName takes precedence over the Common Name).

The HTTPS protocol also supports the wildcard character, *, in host names. For example, if you define the subjectAltName as follows:

subjectAltName=DNS:*.iona.com

This certificate identity would match any three-component host name in the domain iona.com. For example, the wildcarded host name would match either www.iona.com or fusesource.com, but not www.fusesource.com.

[Warning]Warning

You must never use the wildcard character in the domain name (and you must take care never to do this accidentally by forgetting to type the dot, ., delimiter in front of the domain name). For example, if you specified *iona.com, your certificate could be used on any domain that ends in the letters iona.

For details of how to set up the openssl.cnf configuration file to generate certificates with the subjectAltName certificate extension, see Use the CA to Create Signed PKCS#12 Certificates .