Implementation Details of uploading custom certificate
API - UploadCustomCertificate
- API has to be invoked multiple times to upload the certificates and has to be done in order following from root cert, 0 or more intermediate certs followed by server cert and private key.
- Uploading root certificate and the server certificates are mandatory steps.
- Uploading intermediate certificates(s) is optional.
- Self-signed certificates are not supported.
- Reverting back to Realhostip.com or the last certificate is not supported.
- Understanding parameters -
- When API is invoked directly instead if UI make sure the certificates are URL encoded. One way is to use Google chrome - Advanced Rest Client to url encode your certificate (basically it converts the newline into %0A so the certificate becomes 1 line rather than multiple lines ).
- Make sure the certificates are in PEM format.
- API invocation has to be in order ie first the root certificate with id=1 then zero or more intermediate certificates with id =2, 3, 4 etc.
- There is no convention for the name parameter but it would help to name the root certificate as "root", intermediate certificates as "intermediate1", "intermediate2" etc. NOTE - Keep the names always unique.
- domainsuffix should be same as the global config secstorage.ssl.cert.domain/consoleproxy.url.domain = yourdomain.com and for all the API invocations.
DataBase -
'keystore' table stores the certificate.
Schema -
mysql> desc keystore;
+---------------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+---------------------+------+-----+---------+----------------+
| id | bigint(20) unsigned | NO | PRI | NULL | auto_increment |
| name | varchar(64) | NO | UNI | NULL | |
| certificate | text | NO | | NULL | |
| key | text | YES | | NULL | |
| domain_suffix | varchar(256) | NO | | NULL | |
| seq | int(11) | YES | | NULL | |
+---------------+---------------------+------+-----+---------+----------------+
SSVM
- SecStorageSetupCommand -
- All ssvms are rebooted when UploadCustomCertificate is invoked for server cert and private key. As part of ssvm agent connect with MS, a command called SecStorageSetupCommand containing all the certs and the key is sent to ssvm (you wont see the certs as it is sensitive information and not logged).
- On the ssvm side the root cert is inserted into the keystore.
- For apache server a server cert. file, a key file and a certificate chain file (consisting of certs from root cert to the intermediate cert) are created in the appropriate location and location put into the config file.
- SSVM acts as a server for download template/volume/iso operations and during copyTemplate if it is in the source zone. It uses an Apache webserver when acting as server.
- It acts as a client during copyTemplate operation if it is in the destination zone. SSVM uses a Java client when acting as a client.
- SSVM has a java keystore which should have the root certificate in the keystore so that when it tries to download from the url it can validate the chain presented by the server against the known root.
Use the command below to list all certs in the keystore
keytool -list -keystore /usr/local/cloud/systemvm/certs/realhostip.keystore -storepass vmops.com
CPVM
CPVM acts as a server only and uses Java HTTP webserver
Every time CPVM starts up, the keystore is created in-memory by management server and the data sent to CPVM
CPVM uses this keystore to configure the Java webserver with right private key and certificate
The key is saved with label “CPVMCertificate” in keystore
Every time uploadSSL API is called, CPVM reboots
Will be enhanced to reboot only when full chain is uploaded
CPVM has an in-memory keystore (similar to SSVM’s realhostip.keystore)
TroubleShooting
Basics
Any issues with SSVM functionality -
...