1.8.5 SSL SecurityWarning: Certificate has no subjectAltName

The software described in this documentation is either no longer supported or is in extended support.
Oracle recommends that you upgrade to a current supported release.

1.8.5 SSL SecurityWarning: Certificate has no `subjectAltName`

When you configure a Ceph Object Gateway instance and enable SSL you must create an SSL certificate. If the certificate does not have the v3 extension enabled and the subjectAltName set within the certificate, a warning message is displayed when a client such as the Swift client attempts to access the gateway:

/usr/lib/python2.7/site-packages/urllib3/connection.py:251: SecurityWarning:
Certificate has no `subjectAltName`, falling back to check for a `commonName`
for now. This feature is being removed by major browsers and deprecated by
RFC 2818. (See https://github.com/shazow/urllib3/issues/497 for details.)

If a subjectAltName extension of type dNSName is present, this is used as the identity. Otherwise, the Common Name field in the Subject field of the certificate is used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

To prevent the warning from appearing at all, do the following:

In the working directory where you are generating the key and certificate, create a copy of the template OpenSSL configuration file:
```
# cp /etc/pki/tls/openssl.cnf ./
```
Modify the configuration file template at ./openssl.cnf and make the following changes:
- In the section [ req ] make sure that the following line is uncommented and not preceded with a # character:
```
req_extensions = v3_req # The extensions to add to a certificate request
```
- In the section [ v3_req ], add the following line to the end of the parameters in this section:
```
subjectAltName = @alt_names
```
- Add a section to the end of the configuration file:
```
[ alt_names ]
DNS.1 = hostname.example.com
```
  Replace hostname.example.com with the fully qualified domain name for the host that you are creating the certificate for.

Generate your certificate key, as normal:

# openssl genrsa -out hostname.example.com.key 2048

Use the certificate key and the new openssl.cnf file to create a Certificate Signing Request (CSR):

# openssl req -new -key hostname.example.com.key \
-out hostname.example.com.csr -extensions v3_req -config openssl.cnf

You may either use the generated CSR to obtain a signed certificate from a recognized Certificate Authority (CA). Or, for testing purposes, you may use this to generate a self-signed certificate as follows:
- Create a new configuration file, v3.cnf, that can host the information for the v3 requirements. Edit it to contain the following lines:
```
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = hostname.example.com
```
- Run the following OpenSSL command to generate a self-signed certificate using the CSR and your local key:
```
# openssl x509 -req -days 365 -in hostname.example.com.csr -signkey hostname.example.com.key \
> -out hostname.example.com.crt -extensions v3_req -extfile v3.cnf
```

Copy the key, CSR and certificate to the usable location on the host:

# cp -f hostname.example.com.crt /etc/pki/tls/certs/
# cp -f hostname.example.com.csr /etc/pki/tls/private/
# cp -f hostname.example.com.key /etc/pki/tls/private/

Create a single PEM file containing both the key and certificate, that can be used by the Ceph Object Gateway when it is started:

# cp hostname.example.com.crt hostname.example.com.pem
# cat hostname.example.com.key >> hostname.example.com.pem
# cp hostname.example.com.pem /etc/pki/tls/

(Bug 24424028)