About digital certificates
Digital certificates verify the ownership of a public key by the named subject of the certificate, and are used to create secure connections between systems over the Internet.
- A self-signed certificate is an identity certificate signed with its own private key. With a self-signed certificate, the values of the certificate can only be trusted by the entity itself. The security of a self-signed certificate can be compromised, because the entity possesses the signing key and can generate a new certificate with different values at any time.
- A certificate authority (CA) is third-party that issues a digital certificate to verify the ownership of a public key by the named subject of the certificate. This ensures the reliability of the private key that corresponds to the certified public key. A common use for certificate authorities is to sign certificates used in HTTPS, the secure browsing protocol.
The differences between CA signed and self-signed certificates are in the level of security that the certificate ensures. A trusted certificate protects against malicious attacks that can happen when data is en route over the internet from one system to another.
Interana comes with a self-signed certificate that is sufficient for getting a system up and running, or for operating in test environments, but is not recommended for production environments.
If you don't have a valid certificate, you can use the
--unsafe option with CLI commands until a valid cert is acquired.
Replacing the Interana self-signed certificate
For production environments, it is recommended that you replace the Interana self-signed certificate with a trusted certificate. This document covers the following topics:
- Creating a Certificate Signing Request (CS).
- Replacing a self-signed certificate with a trusted certificate.
1. Creating a Certificate Signing Request (CSR)
In this task you create a CSR using OpenSSL.
To create a CSR with OpenSSL, do the following:
- Log in to the Interana config node.
- Enter the following command, replacing company_name with a unique name for your company that you will recognize. This creates two files in your local directory:
openssl req -new -newkey rsa:2048 -nodes -keyout company_name.key -out company_name.csr
The results you see should be similar to the following.
... Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:CA Locality Name (eg, city) :Menlo Park Organization Name (eg, company) [Internet Widgits Pty Ltd]:Company, Inc. Organizational Unit Name (eg, section) :Operations Common Name (e.g. server FQDN or YOUR name) :interana.companyname.com <-- THIS MUST MATCH THE FULL URL THE COMPANY WILL USE Email Address :email@example.com Please enter the following 'extra' attributes to be sent with your certificate request. A challenge password : <LEAVE BLANK> <-- if you don't leave this blank, starting the front end CLI will ask for a password. An optional company name :optional
- Send the CSR files in a secure fashion to a trusted Certificate Authority (CA) of your choice. You will receive a signed cert from the CA in return.
- The signed certificate you receive, may need to be bundled with an intermediate CA Certificate supplied by the CA. These instructions vary. The following are several examples:
- Thawte — Downloading Intermediate CA bundle for SSL123
- Symantec (Verisign) — Symantec Intermediate CA Certificates
- GoDaddy — What is an Intermediate Certificate?
- DigiCert — Root Certificates
- AZURE ONLY: If you get a .pfx file back, do the following:
a. Decrypt the certificate and key, and enter a passphrase when prompted for for an Import password.
openssl pkcs12 -in key_cert_bundle.pfx -nocerts -out keyfile.key
openssl pkcs12 -in key_cert_bundle.pfx -clcerts -nokeys -out certfile.crt
b. De-authenticate the key file, so you won't have to re-enter the Import password every time nginx restarts. Use your passphrase when prompted for an Import password.
openssl rsa -in keyfile.key -out nopass.key
2. Replacing a self-signed certificate with a trusted certificate
You received a signed certificate from a trusted CA and bundled it with an intermediate CA, if needed. You are now ready to replace the Interana self-signed certificate with your CA signed certificate.
You will be replacing the existing files with the same name, so you won't have to modify the nginx config. However, restarting ia-nginx is required.
To replace a self-signed certificate with a CA signed certificate, do the following:
- Log in to the Interana API node.
- Make a backup copy of the existing certificate and key files in the
cd /opt/interana/nginx/ssl mv certificate certificate.orig mv key key.orig
- Copy the signed certificate you received from the CA to the
/opt/interana/nginx/ssldirectory and replace the existing interana-cert.perm file.
cp signed_cert.cert /opt/interana/nginx/ssl/interana-cert.perm
- Copy your company_name.key file to the
/opt/interana/nginx/ssldirectory and replace the existing interana-key.perm file.
cp company_name.key /opt/interana/nginx/ssl/interana-key.perm
- Restart ia-nginx.
sudo /etc/init.d/ia-nginx restart
- To make sure the certificate is valid, open a web browser and enter the IP address of the API node in the URL field, as shown in the following example. If you do not receive an SSL warning, the certificate is valid.
Now that you've installed Interana and replaced the self-signed certificate, it's time to add your data.