HTTPS Configuration
OpenStack Administrator is able to enable HTTPS for communication between Nexenta Cinder driver and NexentaStor REST API.
Using the default self-signed HTTPS certificates
NexentaStor5
By default a NexentaStor5 Appliance is preinstalled with a self-signed certificate that is used for REST API communication and Nexenta Cinder driver supports HTTPS out of box.
NexentaStor4
- By default a NexentaStor4 Appliance is preinstalled with disabled HTTPS. To enable HTTPS use the following commands on NexentaStor4 Appliances:
nmc@host:/$ setup appliance init
Interface ixgbe1 : Configured as 192.168.1.2/255.255.255.0 with mtu 9000
Interface igb0 (PRIMARY) : Configured as 10.1.1.2/255.255.252.0 with mtu 1500
Interface ixgbe0 : Configured as 192.168.2.2/255.255.255.0 with mtu 9000
Interface igb1 : Unconfigured
Default Gateway : 10.1.1.254 : OK
DNS #1 : 10.1.1.1 : OK
DNS #2 : 10.2.2.2 : OK
DNS #3 : 10.3.3.3 : OK
Reconfigure? No
Your primary interface is : igb0
Web GUI protocol : HTTPS
Web GUI port : 8457
Starting self-signed SSL-certificate for NMV generation.
Country : US
State/Province : Missouri
City/Locality : St. Petersburg
Organization/Company : Art Store, Inc
Organizational unit/Department: Paint Department
Use current machine FQDN 'host.art-store.local' as certificate Common Name(CN)? Yes
Common name : host.art-store.local
Email : thomas.sawyer@art-store.local
Days : 365
Available on https://10.1.1.2:8457/
nmc@host:/$
- Enable REST API HTTPS for the Nexenta Cinder driver and NexentaStor4 backend in cinder.conf:
[nexentastor4_backend]
nexenta_rest_protocol = https
Note: by default, nexenta_rest_protocol is set to auto and Nexenta Cinder driver automatically negotiates the protocol for accessing the REST API endpoint.
Using the custom HTTPS certificates and enabling certificate verification
HTTPS uses SSL/TLS to make the HTTP connection secure, but HTTPS can provide more security if certificate verification is enabled.
Requirements for certificates
Before obtaining and installing SSL certificates, you must understand what certificates are required and their requirements.
- Each NexentaStor host must have its own or wildcard certificate installed.
- In case of a single-name certificate, the common name consists of a single host name (for example, hostname.domain.local), or a wildcard name in case of a wildcard certificate (for example, *.domain.local).
- Each certificate must contain a Subject Alternative Name extension containing a domain name and/or IP address for all additionally used names and/or addresses (for example, HA VIP’s).
Creating a CA and issuing certificates
It’s possible to obtain certificates from an external CA or create your own certification authority and issue certificates.
- Create a CA:
client$ cadmin -t ca -n CA -m ca@art-store.local -u 'Paint Department' -o 'Art Store, Inc' -l 'St. Petersburg' -s Missouri -c US -b 4096 -y 3650
- Create a certificate for the first HA node, using node1.qa.local as common name and vip1.qa.local, vip2.qa.local, 10.1.1.2, 192.168.1.11 and 192.168.1.22 as alternative host names:
client$ cadmin -t server -n node1.qa.local -m ca@art-store.local -u 'Paint Department' -o 'Art Store, Inc' -l 'St. Petersburg' -s Missouri -c US -b 2048 -y 365 -a DNS:node1.qa.local -a DNS:vip1.qa.local -a DNS:vip2.qa.local -a IP:10.1.1.2 -a IP:192.168.1.11 -a IP:192.168.1.22
The Subject's Distinguished Name is as follows
commonName :ASN.1 12:'node1.qa.local'
emailAddress :IA5STRING:'ca@art-store.local'
organizationalUnitName:ASN.1 12:'Paint Department'
organizationName :ASN.1 12:'Art Store, Inc'
localityName :ASN.1 12:'St. Petersburg'
stateOrProvinceName :ASN.1 12:'Missouri'
countryName :PRINTABLE:'US'
Certificate is to be certified until May 22 00:26:10 2020 GMT (365 days)
- Create a certificate for the second HA node, using node2.qa.local as common name and vip1.qa.local, vip2.qa.local, 10.1.1.3, 192.168.1.11 and 192.168.1.22 as alternative host names:
client$ cadmin -t server -n node2.qa.local -m ca@art-store.local -u 'Paint Department' -o 'Art Store, Inc' -l 'St. Petersburg' -s Missouri -c US -b 2048 -y 365 -a DNS:node2.qa.local -a DNS:vip1.qa.local -a DNS:vip2.qa.local -a IP:10.1.1.3 -a IP:192.168.1.11 -a IP:192.168.1.12
The Subject's Distinguished Name is as follows
commonName :ASN.1 12:'node2.qa.local'
emailAddress :IA5STRING:'ca@art-store.local'
organizationalUnitName:ASN.1 12:'Paint Department'
organizationName :ASN.1 12:'Art Store, Inc'
localityName :ASN.1 12:'St. Petersburg'
stateOrProvinceName :ASN.1 12:'Missouri'
countryName :PRINTABLE:'US'
Certificate is to be certified until May 22 00:26:41 2020 GMT (365 days)
Steps for NexentaStor5
- Copy the private host key to a new file called key.pem
client$ cp node1.qa.local.key key.pem
- Copy the host certificate to a new file called cert.pem:
client$ cp node1.qa.local.crt cert.pem
- Create a compressed archive file with the key.pem and cert.pem:
client$ tar cvfz node1.tar.gz key.pem cert.pem
a key.pem 2K
a cert.pem 10K
- Create a filesystem and NFS share on host node1 and upload the node1.tar.gz file to this share (it is possible to use external HTTP(s) or FTP servers):
CLI@node1> filesystem create pool/ssl
CLI@node1> acl set -r A+user:admin:full_set:allow pool/ssl
CLI@node1> nfs share -o uidMap='*:root:@10.10.10.10' pool/ssl
client$ sudo mount 10.1.1.2:pool/ssl /mnt
client$ cp node1.tar.gz /mnt
client$ sudo umount /mnt
Note: 10.10.10.10 - IP address of the remote client.
- Open ssh/CLI session to the host node1 and import the certificate and key to NexentaStor5 Rest API using the following command:
CLI@node1> config set rest.certificate.url = file:///pool/ssl/node1.tar.gz
- Destroy a filesystem:
CLI@node1> filesystem destroy -y pool/ssl
- Check Rest API for the new certificate:
client$ echo | openssl s_client -showcerts -connect 10.1.1.2:8443
Certificate chain
Server certificate
subject=/CN=node1.qa.local/emailAddress=ca@art-store.local/OU=Paint Department/O=Art Store, Inc/L=St. Petersburg/ST=Missouri/C=US
issuer=/CN=CA/emailAddress=ca@art-store.local/OU=Paint Department/O=Art Store, Inc/L=St. Petersburg/ST=Missouri/C=US
...
Steps for NexentaStor4
- Copy the private host key to a remote file called nmv.key:
client$ scp -p node1.qa.local.key root@10.1.1.2:/var/lib/nza/nmv.key
- Copy the host certificate to a remote file called nmv.crt:
client$ scp -p node1.qa.local.crt root@10.1.1.2:/var/lib/nza/nmv.crt
- Enable HTTPS for NexentaStor4 Appliance:
nmc@node1:/$ setup appliance init
Interface ixgbe1 : Configured as 192.168.1.2/255.255.255.0 with mtu 9000
Interface igb0 (PRIMARY) : Configured as 10.1.1.2/255.255.252.0 with mtu 1500
Interface ixgbe0 : Configured as 192.168.2.2/255.255.255.0 with mtu 9000
Interface igb1 : Unconfigured
Default Gateway : 10.1.1.254 : OK
DNS #1 : 10.1.1.1 : OK
DNS #2 : 10.2.2.2 : OK
DNS #3 : 10.3.3.3 : OK
Reconfigure? No
Your primary interface is : igb0
Web GUI protocol : HTTPS
Web GUI port : 8457
SSL certificate for NMV already exists. Generate a new one? No
Available on https://10.1.1.2:8457/
nmc@node1:/$
- Check Rest API for the new certificate:
client$ echo | openssl s_client -showcerts -connect 10.1.1.2:8457
Certificate chain
Server certificate
subject=/CN=node1.qa.local/emailAddress=ca@art-store.local/OU=Paint Department/O=Art Store, Inc/L=St. Petersburg/ST=Missouri/C=US
issuer=/CN=CA/emailAddress=ca@art-store.local/OU=Paint Department/O=Art Store, Inc/L=St. Petersburg/ST=Missouri/C=US
...
Configuring Nexenta Cinder driver
- Copy the CA certificate to the cinder config directory:
cinder$ cp ca.crt /etc/cinder
- Enable REST API HTTPS for the Nexenta Cinder driver and NexentaStor backend in cinder.conf:
[nexentastor_backend]
driver_ssl_cert_verify = True
driver_ssl_cert_path = /etc/cinder/ca.crt
...
Note: If driver_ssl_cert_path is omitted, the system default CA will be used for CA verification.