Generating Multi-Domain (SAN) Certificates

The Subject Alternative Name field lets you specify additional host names (sites, IP addresses, common names, etc.) to be protected by a single SSL Certificate, such as a Multi-Domain (SAN) or Extend Validation Multi-Domain Certificate.

Benefits

• Secure Host Names on Different Base Domains in One SSL Certificate: A Wildcard Certificate can protect all first-level subdomains on an entire domain, such as *.example.com. However, a Wildcard Certificate cannot protect both www.example.com and www.example.net.
• Virtual Host Multiple SSL Sites on a Single IP Address: Hosting multiple SSL-enabled sites on a single server typically requires a unique IP address per site, but a Multi-Domain (SAN) Certificate with Subject Alternative Names can solve this problem. Microsoft IIS and Apache are both able to Virtual Host HTTPS sites using Multi-Domain (SAN) Certificates.
• Greatly Simplify Your Server's SSL Configuration: Using a Multi-Domain (SAN) Certificate saves you the hassle and time involved in configuring multiple IP addresses on your server, binding each IP address to a different certificate, and trying to piece it all together.

Example

A multi-domain SAN certificate will have a Subject Alternative Name extension that can list both www.abcd.com and abcd.com plus some additional SANs secured by a single certificate. Because the name abcd.com is listed in the certificate, a web browser will not complain if one visits site at https://abcd.com without the 'www' in the name.

CSR (Certificate Signing Request)

CSR is a block of encoded text that is given to a Certificate Authority when applying for a signed SSL Certificate. It is usually generated on the server where the certificate will be installed and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country. It also contains the public key that will be included in the certificate. A private key is usually created at the same time that you create the CSR, making a key pair. A CSR is generally encoded using ASN.1 according to the PKCS #10 specification.

A certificate authority will use a CSR to create your SSL certificate, but it does not need your private key. You need to keep your private key secret. The certificate created with a particular CSR will only work with the private key that was generated with it. So if you lose the private key, the certificate will no longer work.

A CSR contains following fields:

• CN (Common Name): The fully qualified domain name (FQDN) of your server. This must match exactly what you type in your web browser or you will receive a name mismatch error. Example: *.abcd.com or mail.abcd.com
• O (Organization): The legal name of your organization. This should not be abbreviated and should include suffixes such as Inc, Corp, or LLC. Example: ABCD Inc.
• OU (Organizational Unit): The division of your organization handling the certificate. Example: Finance
• L (City/Locality): The city where your organization is located. Example: London
• ST (State/County/Region): The state/region where your organization is located. This shouldn't be abbreviated. Example: Greater London
• C (Country): The two-letter ISO code for the country where your organization is located. Example: GB
• emailAddress (Email address): An email address used to contact your organization. Example: YourEmailAddress@domain.name
• publicKey (Public Key): The public key that will go into the certificate. It is part of the CSR.
  

Public signed SSL certificate

To create a signed SSL Certificate corresponding to your private key, you have three options here:

1. Self-signing - Easy, free, and quick. Not trusted by browsers.
2. Creating a certificate authority (CA) - Not difficult, but likely more effort. Still isn’t trusted by browsers.
3. Paying a CA to create your certificate for you - Can be cheap (£10), pretty easy, and is trusted by browsers. letsencrypt provides a free service to sign your certificate.

We will use OpenSSL for this.
To generate a Key Pair (private key) and Certificate Signing Request (CSR), please do the following:

1. Login to the host for which you need a signed certificate.
2. Get host's Fully Qualified Domain Name (FQDN):
   

   host `hostname` | sed 's/\([^ ]*\)\ .*/\1/'
   

3. Create a text file containing certificate information for the machine named `fully.qualified.domain.name`
   

   [req]
      default_bits = 2048
      prompt = no
      default_md = sha256
      req_extensions = req_ext
      distinguished_name = dn
   
      [ dn ]
      C=GB
      ST=Greater London
      L=London
      O=Organisation Name
      OU=Organisation Unit Name
      emailAddress=YourEmailAddress@domain.name
      CN=fully.qualified.domain.name
   
      [ req_ext ]
      subjectAltName = @alt_names
   
      [ alt_names ]
      DNS.1=fully.qualified.domain.name
      DNS.2=hostname
   

   NOTE: Make sure that you specify CN in alt_names section also. For CA6 certs, the CN is not automatically added to the SAN. If SAN is present, the CN is ignored and will not be trusted.
   
4. Generate CSR and a 2048 bit RSA private key file:
   

   openssl req -new -sha256 -nodes -out hostname.csr -newkey rsa:2048 -keyout hostname.key -config <( cat cert.txt )
   

5. To certify the certificate, submit the generated CSR request to a certifying authority. They will issue a public SSL certificate for you.
6. Please verify the CSR, to ensure all information is correct. Use the following command:
   

   openssl req -noout -text -in hostname.csr
   

7. As an alternative, to generate self-signed certificate, run:
   

   openssl x509 -req -sha256 -days 3650 -in hostname.csr -signkey hostname.key -out hostname.crt
   

   You can run combine all above steps in a single command to generate self-signed certificate:
   

   openssl req -x509 -nodes -days 3650 -subj "/C=GB/ST=Greater London/L=London/O=Organisation/OU=OrgUnit/CN=fully.qualified.domain.name/emailAddress=YourEmailAddress@domain.name" -newkey rsa:2048 -keyout hostname.key -out hostname.crt
   

   Here -nodes is to generate key in password-less mode. -nodes doesn't mean "nodes" but rather "no DES"
   Add -subj to suppress questions about the contents of the certificate. This is useful in automation.
   
8. Please verify the certificate text and subject, to ensure all information is correct. Use the following command:
   

   openssl x509 -noout -text -in hostname.crt
   openssl x509 -noout -subject -in hostname.crt
   

9. Create a PEM file, as many daemons use a PEM file that combines the .key and the .crt file together:
   

   cat hostname.key hostname.crt > hostname.pem
   

Connecting to services hosted using self-signed or custom CA

1. Download the public SSL certificate from the web service URL:
   

   keytool -printcert -rfc -sslserver abcd.com > ./abcd.public.cert.pem
   

2. Add the downloaded certificate to your JDK trust store:
   

   keytool -keystore ${JAVA_HOME}/lib/security/cacerts -storepass changeit -importcert -file ./abcd.public.cert.pem -alias abcd.com
   

3. Alternatively, you can create a custom Java Keystore and add the public certificates of the services that you want to trust and connect to (using Java):
   

   keytool -genkey -keyalg RSA -alias customJavaKeyStore -keystore customJavaKeyStore.jks -storepass customJavaKeyStorePassword -validity 3650 -keysize 2048
   keytool -keystore customJavaKeyStore.jks -storepass customJavaKeyStorePassword -import -trustcacerts -file caRootCertFile.crt -alias caRootCertAlias
   keytool -keystore customJavaKeyStore.jks -storepass customJavaKeyStorePassword -import -file "hostname.crt" -alias hostNameCert
   

   where caRootCertFile.crt is the file containing the root certificate, caRootCertAlias is the alias representing the certificate, and customJavaKeyStore.jks is the file containing your trust store.
   
4. Add the certificate to the start-up parameters:
   

   -Djavax.net.ssl.trustStore=customJavaKeyStore.jks -Djavax.net.ssl.trustStorePassword=customJavaKeyStorePassword