About certificates
Background
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.
Certificate use
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: These are those owned and managed by Certificate Authorities (CAs). CAs are entities that issue digital certificates.
- Intermediate certificates: These 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-entity certificates.
- Entity certificates: An individual or a company creates these from one of their intermediate certificates for individual use.
Create certificate chains
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.pemWhen chained, groupings of certificates resemble the following:
-----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-----Create a chain that contains each certificate. Start with the entity certificate, followed by the intermediate certificate, and then the root certificate, if required. Each certificate must directly certify the one before it. The root certificate is only required when using self-signed certificate chains. For EAP-TTLS or EAP-GTC, also include the entity private key.
Convert between certificate formats
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 PEM
openssl x509 -in cert.crt -outform PEM -out cert.pemCER to PEM
openssl x509 -in cert.cer -outform DER -out cert.pemEAP-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 PFX
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crtSample command to convert to P12
openssl pkcs12 -export -out certificate.p12 -inkey privateKey.key -in certificate.crtOther input and conversion options exist. See the openssl documentation and the openssl man page for more information.