The HTTPS specification mandates that HTTPS clients must 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 can 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. 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 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) at 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 through the Common Name (CN) in the subject DN of the certificate.
For example, if a server supports secure TLS connections at the following URL:
https://www.progress.com/secure
The corresponding server certificate would have the following subject DN:
C=IE,ST=Co. Dublin,L=Dublin,O=Progress, OU=System,CN=www.progress.com
Where the CN has been set to the host name, www.progress.com.
For details of how to set the subject DN in a new certificate, see Generate a certificate and private key pair.
Using the subject DN’s Common Name for the certificate identity has 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.progress.com fusesource.com
Then you can define a subjectAltName that explicitly lists both of these
DNS host names. If you generate your certificates using the openssl
utility, edit the relevant line of your openssl.cnf configuration file
to specify the value of the subjectAltName extension, as follows:
subjectAltName=DNS:www.progress.com,DNS:fusesource.com
Where the HTTPS protocol matches the server host name against 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, you can define the subjectAltName as follows:
subjectAltName=DNS:*.fusesource.com
This certificate identity matches any three-component host name in the domain
fusesource.com.
![[Warning]](imagesdb/warning.gif) | 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,
|
 |  |  |
 |
