Troubleshooting SSL certificate installation
These troubleshooting tips can help you if you encounter the following error messages or issues.
To install an SSL certificate on Access Server, refer to this tutorial.
Issue: This message occurs when your private key doesn’t match the one you used to sign the CSR submitted to your certificate authority.
Resolution: Ensure you use the same key file you used to generate your CSR.
If you lost this file, restart the certificate generation process and ask your certificate authority for a replacement. The private key is unique and can’t be recreated. If you've lost it, the signed public certificate also becomes useless.
Issue: This message occurs when your private key is encrypted with a passphrase, and Access Server doesn’t know how to decrypt it (i.e., it doesn’t know the passphrase).
Resolution: Decrypt your private key:
Decrypt your private key by running this example command on the command line with the OpenSSL program.
openssl rsa -in server.key -out decrypted.key
Provide your passphrase.
Load the resulting, decrypted private key file into your Access Server.
Important
Access Server doesn't support passphrase-encrypted private key files for the web services.
Issue: This error occurs with an invalid private key and is usually part of an error message like this:
Private Key Load Error [('PEM routines', 'PEM_read_bio', 'no start line')] (OpenSSL.crypto.Error)Resolution: Ensure you provide the correct file. Check that you didn’t accidentally supply your public certificate as the private key, or vice-versa. The private key field in Access Server only accepts a valid private key.
If you’re sure the file is valid, check the formatting of the private key file, such as with or without line breaks, using a different EOL (End-of-Line) standard that isn’t acceptable. You may try to manually fix this problem yourself with proper EOL conversion tools or by contacting your certificate authority for assistance. We often see this problem with certain providers of SSL certificates that generate the private key for you. They may be providing it with Windows-type EOL characters, which can cause a problem. Usually, they can help you obtain a Linux-compatible version, or you can use a text editing tool to convert the file format to a type that doesn't contain these additional characters.
Issue: The file supplied seems like valid keying material, although it doesn't look like a server certificate was provided.
Resolution: It’s possible that the CA bundle and the server certificate were accidentally swapped. Try to swap the order of the CA bundle and the certificate and try again. If this doesn’t work, ensure you provide the signed certificate you received from your CA, not the CSR you generated on your machine. Access Server does not need or want the CSR; it’s only used to make the certificate signing request with your certificate authority.
Issue: This message can occur in various programs that try to verify the identity of a server using its public certificate. It can happen in OpenVPN Connect but also in a web browser or a test program for SSL connections. The error occurs when the path from your server's certificate to a trusted root authority certificate can’t be established.
Resolution: Certificates are hierarchical; each certificate knows its direct parent above it using a unique fingerprint. Using this method, a chain can be formed going from your server certificate to the certificate issuer and from there to a (trusted) root authority. Sometimes there are more steps. Sometimes the direct parent is the root authority. But in most cases, there are steps in between called intermediaries. If there is one, only one intermediate certificate must be added to your chain of certificates. If there are more, you can copy-paste them into one file, one after the other, to make an intermediary bundle file containing all the intermediaries to complete the path of trust. If you already had a working certificate but now have a new one from a different issuer, you must update your intermediaries.
On the OpenVPN Connect v2 client, the intermediaries are stored on disk with the client, and to update this, you would need to update OpenVPN Connect v2. We recommend using the same issuer when renewing a certificate, and your clients use OpenVPN Connect v2 with server-locked profiles. It doesn't make for user-locked and auto-login as the web interface only gets called when using server-locked.
On the OpenVPN Connect v3 client, we use the certificate store in the operating system to determine a path of trust.