In general, Secure Socket Layer(SSL/X509) certificates are used to:
- Establish a secure connection between a client and a server. For example:
- Client: A browser or VPN client
- Server: <your-org>.okta.com or the Okta RADIUS agent
- Encrypt communication to ensure that sensitive information is safe.
- Authenticate an organization's identity.
Certificates secure communications for subsystems (like Okta RADIUS agents) when they use Extensible Authentication Protocol/Tunneled Transport Layer Security (EAP/TTLS) or personal identify verification (PIV) smart cards.
Certificate issuers and types
From an issuer's perspective, there are three certificate types:
- Certificate Authority (Root CA) certificates are those owned and managed by certificate authorities (CAs). CAs are entities that issue digital certificates.
- Intermediate certificates are granted to a company or by a company to a subordinate division. Intermediate certificates are often used to sign lower level intermediate certificates or end certificates.
- Entity certificates are created by an individual or a company from one of their intermediate certificates for individual use.
Certificate chains are groupings of certificates. Okta typically requires all certificate chains to be in Privacy Enhanced Mail (PEM) format.
Certificate chains concatenate all certificates in order, from the entity to the trusted root. If there are multiple intermediate certificates, they must be included in the chain.
Certificates can be combined into a certificate chain using an editor or command line tools. For example, to concatenate an entity certificate, an intermediate certificate, and the entity's private key in Linux:cat entity.pem intermediate.pem entity-primarykey.pem > certificate-chain.pem
When chained, groupings of certificates resemble:
-----BEGIN CERTIFICATE----- .... (entity certificate contents) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- .... (Intermediate certificate contents) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- .... (Trusted root certificate contents (Optional. Only required for self-signed chains)) -----END CERTIFICATE----- -----BEGIN RSA PRIVATE KEY----- .... (entity private key contents) -----END RSA PRIVATE KEY-----
You must create a chain that contains each certificate, starting with all intermediate certificates followed by the entity certificate, but excluding the trusted CA root certificate. The root certificate is only required when using self-signed certificate chains. For EAP-TTLS or EAP-GTC, also include the entity private key.
If you have received or generated certificates in another format they may need to be converted to PEM before being concatenated and then uploaded. Tools like openssl can convert a certificate from one format to another.
The following examples demonstrate converting various formats to .PEM.
CRT to PEMopenssl x509 -in cert.crt -outform PEM -out cert.pem
CER to PEMopenssl x509 -in cert.cer -outform DER -out cert.pem
Additionally, EAP-TTLS and EAP-GTC protocols support pfx and p12 formats, which allow the specification of a password to protect an associated private key.
Convert to PFXopenssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt
Sample command to convert to P12openssl pkcs12 -export -out certificate.p12 -inkey privateKey.key -in certificate.crt
Multiple additional input and conversion options exist. See the openssl documentation and the openssl man page for more information.