Recreating Server Certificates on OES Linux
Unfortunately, the extremely useful netware tool, PKIDiag, is not available in Linux. However, the tasks that PKIDiag performs can be duplicated in Linux. This process is very useful if you have to update a server certificate (the default expiration time for a server certificate is two years, so this may happen often if you went with the default settings).
eDirectory by default runs its own Certificate Authority (CA). A CA is nothing more than a self-signed certificate that is used to sign other certificates as being trusted by the Certificate Authority. When you trust the Certificate Authority by importing its Trusted Root Certificate (which is nothing more than a self-signed public key certificate), you automatically trust all certificates that have been signed by the Certificate Authority. The Novell Certificate Manager automates and secures the process of signing certificates, and allows these certificates to be stored in eDirectory for easy access and retrieval.
When an OES Linux server is joined to an eDirectory tree, it generates a private key and requests two certificates from the Certificate Authority:
- SSL CertificateDNS - A certificate that can authenticate the server based on its DNS name.
- SSL CertificateIP - A certificate that can authenticate the server based on its IP Address.
The SSL CertificateIP is rarely used these days as most networks use DNS.
OES Linux then copies the SSL CertificateDNS and its associated private key to /etc/ssl/servercerts. These certificates are then used by all SSL-capable programs on the server, such as iPrint, Tomcat, iManager, etc.
OES Linux also copies the Trusted Root Certificate for the CA to:
- /etc/opt/novell/SSCert.pem - a text version of the certificate
- /etc/opt/novell/SSCert.der - A binary-formatted version of the certificate
- /etc/opt/novell/certs/SSCert.pem - a text version of the certificate
- /etc/opt/novell/certs/SSCert.der - A binary-formatted version of the certificate
Preparing the Server
Deleting existing SSL Certificates
First, you need to delete the SSL CertificateDNS and SSL CertificateIP certificates for the server, if they exist. This will allow the server to request new certificates to be minted and signed by the eDirectory CA. These certificates are normally located in the same context as your server object in eDirectory.
Minting New Certificates
To mint (create) new certificates for the server, simply run ndsconfig upgrade. When prompted, enter your admin username and password:
Exporting the Server Certificate
After doing this step, you should have new SSL CertificateDNS and SSL CertificateIP objects for the server. Unless you access iManager and related services via IP address, such as http://192.168.1.1/nps/iManager.html, you should use the SSL CertificateDNS.
To export the SSL CertificateDNS certificate:
- In iManager, go to eDirectory Administration -> Modify Object
- Select the SSL CertificateDNS - YourServerName certificate object, which should be in the same eDirectory context as your server object and click OK
- Go to the Public Key Certificate (Self Signed Certificate) tab of the certificate object and click Validate. It should come back as Valid. If not, there is something wrong with your Certificate Authority and you should rectify this problem and regenerate the certificates before continuing.
- Select Export.
- Select Yes when asked if you want to export the private key with the certificate.
- Assign the private key a password. This will be used to protect the private key while it is in transit to the new server. This password will be removed in a future step.
- Save the resulting pkcs12 file (Personal Information Exchange format) to a secure location on your server. For this example, we will save it to /root/downloads/sslcert.pfx.
Installing the Certificate on the Server
The pkcs12 file we saved earlier contains the private key, public key certificate for the server, and the eDirectory CA Trusted Root Certificate. We now need to extract these different components and place them in their respective locations on the server. The following examples assume you saved the pfx file from above to /root/downloads/sslcert.pfx.
Extracting the files from PFX
At this point, we need to extract the following individual components from the encrypted PFX file:
- Private Key - The private key that the server uses to encrypt SSL traffic
- Server Certificate - The public key certificate that the server identifies itself with to clients
- eDirectory CA Trusted Root - The self-signed public key certificate that identifies the eDirectory Certificate Authority.
You will be prompted for a password for the following commands. This is the same password you used when you exported the certificate.
Installing the Private Key
Command: openssl rsa -in ~/downloads/servcert.pem -out /etc/ssl/servercerts/serverkey.pem
Installing the Public Key Certificate
Command: openssl x509 -in ~/downloads/servcert.pem -out /etc/ssl/servercerts/servercert.pem
Installing the Trusted Root Certificate (binary version)
Command: openssl x509 -outform der -in /etc/opt/novell/SSCert.pem -out /etc/opt/novell/certs/SSCert.dercorrected command
Command: openssl x509 -outform der -in /etc/opt/novell/certs/SSCert.pem -out /etc/opt/novell/certs/SSCert.der
Additional Steps if required
Depending on what you have installed on the server you will need to update the certificates for other services.
Linux User Management will continue to fail to start namcd until namconfig -k is run
Other services possibly effected:
- iManager - See TID# 10097841
- LDAPS - See TID#10066259
- Apache - See TID# 3911570
At this point your server now has an eDirectory-enabled certificate. If you connect to the server using its DNS name, you should be able to view the certificate. If you import the Trusted Root Certificate into your browser, you shouldn't even get a certificate warning.
The vast majority of these steps could be easily scripted into a single command. Here is such a script.
These steps are necessary if you ever change your CA, which can be a good idea if you want it to have a better name than the default (ugly) version of just the name of the tree. Another article on recreating your CA with a prettier name is forthcoming.
Get stuck, need clarification, or just curious about something? Please post in the Discussion Page.