Subject Alternative Name (SAN) allows a SSL certificate to specify multiple host names, which allows one SSL certificate to be used in accessing multiple servers.
Note: At least one of the Subject Alternative Names or the Common Name(CN) must match the machines hostname.
As of Google Chrome, Version 58, all SSL Certificates must include a SAN as the common name is ignored and SAN entries are used instead. For example:
If a certificate is SSL Certificate is used without a SAN, for a REST service running on Progress Application Server for OpenEdge (PASOE), the following error is returned by the Browser when accessing the service: "NET::ERR_CERT_COMMON_NAME_INVALID"
Assume the SSL Certificate will be created following the instructions outlined in the following KB article:
How to configure and test a PASOE instance for secure communications. Prior to configuring a PASOE instance for secure communications, Subject Alternative Name (SAN) information needs to be included in the SSL certificate used as follows:
1. Make a backup copy of
<OpenEdge installation directory>\keys\policy\pscpki.cnf2. Uncheck the readonly attribute of the file then open DLC\keys\policy\pscpki.cnf in a text editor
3. Add
req_extensions to the
[ req ] Section:
[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
req_extensions = v3_req4. Add
[ v3_req ] and
[alt_names] Sections after all entries between
[ req_attributes ] and
[ x509v3_extensions ] and just before
[ x509v3_extensions ] :[ req_attributes ]
#challengePassword = A challenge password
#challengePassword_min = 4
#challengePassword_max = 20
#unstructuredName = An optional company name
certs = $ENV::DLC/certs
default_md = sha256
default_bits = 2048
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = <fully qualified domain name of the first server hosting the service as it will be used in the web browser>
DNS.2 = <fully qualified domain name of the second server hosting the service as it will be used in the web browser>#An example might be as follows:
#DNS.1 = myRestServer1.domain.com
#DNS.2 = MyRestServer2.domain.com
#DNS.3 = MyRestServer3.domain.com
#DNS.4 = MyRestServer4.domain.com
[ x509v3_extensions ]
basicConstraints=critical,CA:FALSE,pathlen:0
#keyUsage=serverAuth
5. After adding the Subject Alternative Name (SAN) information to pscpki.cnf, follow the steps outlined in KB article "
How to configure and test a PASOE instance for secure communications?" to:
- Create a certificate request,
- Get a signed certificate,
- Add the certificate to the keystore
- Use the certificate with a client.
While not explicitly mentioned, the steps in KB article "
How to configure and test a PASOE instance for secure communications?" use the <DLC>\keys\policy\pscpki.cnf OpenSSL configuration file for creating the Certificate Signing Request (CSR). Certificates created in this way can be used with an ABL client, all web browsers and REST clients (e.g. SoapUI, POSTMAN, etc.).
After getting the signed certificate, the following command can be executed in a Proenv session to check for the SAN entries:
sslc x509 -in <signed certificate file name> -text -noout
The SAN entries are in the "X509v3 extensions" section within the "X509v3 Subject Alternative Name" property.
With these changes, the web service can be accessed from a web browser by specifying one of the SAN hostnames. For example:
https://myRestServer1.domain.com:8811/myCustomer/rest/myCustomerService/CustomerBE
