X.509 certificates: what they are & how to get one

X.509 certificates are something you will likely come across when setting up SAML SSO. 

These certificates are used to sign and encrypt SAML assertions between your application (the service provider) and the identity provider (IdP), such as Okta and Microsoft Entra. Signing ensures the data hasn't been tampered with and is from a trusted source, while encryption ensures only the intended recipient can read the information.

In this article, we'll explain what an X.509 certificate is, how it works, and why you need one if you're dealing with sensitive user information. We'll also provide a step-by-step guide on generating one, including a hard and an easy way.

What is an X.509 certificate?

An X.509 certificate is a digital document that uses a digital signature to bind a public key with an identity. These certificates use public key cryptography to verify the certificate holder's identity. They contain information like the issuer (the entity that issued the certificate), the validity period (when the certificate starts and ends), and the public key (used for encrypting messages or verifying digital signatures).

These certificates allow you to confirm the authenticity of the server you're communicating with and encrypt the information being exchanged. Almost every secure website, VPN, Wi-Fi network, and IoT device relies on X.509 certificates to maintain security and trust.

Certificate authorities (CAs) are the most common sources for obtaining X.509 certificates.

How do X.509 certificates work?

X.509 certificates use public key infrastructure (PKI), which operates on the principles of public key cryptography, where a pair of keys is used for encryption and decryption.

Here’s how it works:

• A certificate authority (CA) that issues an X.509 certificate vouches for the certificate holder's identity by signing the certificate with a private key. An X.509 certificate contains the matching public key and identity details the CA has digitally signed. 
• Anyone can use this public key to encrypt data, which can only be decrypted by the corresponding private key, held secretly by the certificate's owner. 
• Similarly, data signed with the private key can be verified with the public key, proving the data's integrity and the sender's identity.

X.509 certificates enable digital signatures, where an entity can sign a document or message with its private key. Recipients can use the public key in the signer’s certificate to verify the signature, ensuring the data hasn’t been tampered with and providing proof of the signer’s identity.

Example: securing web traffic using HTTPS

Let’s apply this process to a familiar scenario: Securing web traffic using HTTPS.

1. When you connect to an HTTPS-secured website, the server presents its X.509 certificate to your browser.
2. Your browser checks the certificate's digital signature, confirms it was issued by a trusted CA, and confirms that it is valid and not expired.
3. Once verified, your browser uses the server’s public key (from the certificate) to encrypt data sent to the server. Only the server, with its private key, can decrypt this data. Similarly, the server can encrypt data sent to your browser, which your browser can decrypt.

Why are X.509 certificates used?

Gain user’s trust

When someone connects to your website, the X.509 certificate helps verify your identity to the user. The certificate contains details like your domain name, company information, and the certificate authority. This allows users to confirm they are connected to your website and not an imposter.

Data integrity

X.509 certificates also help ensure that data between your website and the user or system remains intact and unchanged. They use encryption to prevent third parties from reading or altering the information. If someone tries to tamper with the data, it will invalidate the digital signature, making any changes detectable. 

This is particularly important for sensitive information like passwords, credit card numbers, or account details.

In the context of SAML SSO, these certificates encrypt SAML responses and requests to prevent tampering with authentication data.

Standardized and ubiquitous

Because it's standardized, X.509 certificates work across all major browsers, operating systems, and web servers. This standardization makes it easier for developers and administrators to implement security measures without building custom solutions.

How to get an X.509 certificate (the hard way)

Generating an X.509 certificate typically involves creating a key pair (private and public keys) and then creating a Certificate Signing Request (CSR), which is then submitted to a certificate authority (CA) for signing.

Here's a step-by-step guide for generating an X.509 certificate using OpenSSL, a widely used open-source tool for PKI tasks.

Step 1: Install OpenSSL

Install OpenSSL in your development environment.

Step 2: Generate a private key

This key will generate the CSR and secure and decrypt transmissions later. Keep it secure and confidential.

In your terminal, run the following:

	
openssl genpkey -algorithm RSA -out privatekey.pem -pkeyopt rsa_keygen_bits:2048
	

This command generates an RSA private key of 2048 bits and saves it to a file named privatekey.pem. You can adjust the bit length for more security, but 2048 is generally considered sufficient for most purposes. Other algorithms you can use are ECC (Elliptic curve cryptography) and DSA (Digital signature algorithm).

Step 3: Generate a Certificate Signing Request (CSR)

With your private key, the next step is to generate a CSR. The CSR contains information that will be included in your certificate, such as your organization's name, common name (domain name), and country. The CA will use this information to create your certificate.

In your terminal, run the following code:

	
openssl req -new -key privatekey.pem -out csr.pem
	

You will be prompted to enter details like your country code, state, organization name, and common name (domain name). This information forms the Distinguished Name (DN) of your certificate request.

Step 4: Generating the X.509 certificate

You can submit the CSR to a CA to sign or self-sign your certificate for internal use, testing, or development.

To self-sign, run this command:

	
openssl x509 -signkey privatekey.pem -in csr.pem -req -days 365 -out certificate.pem
	

This creates a certificate (certificate.pem) from the CSR, signed with the same private key and valid for the specified duration, commonly set to 365 days.

For a certificate clients will trust, submit your CSR to a CA. The process will vary depending on the CA, but it generally involves uploading the CSR file and verifying your domain or organization's ownership. Once verified, the CA will issue your certificate, typically in a .crt file.

In the context of SAML SSO, an X.509 certificate is the public key certificate SPs use to verify the authenticity of SAML assertions. Some Identity Providers (IdPs) may also require or provide the option to use a SAML signing certificate for the SAML request. In these cases, the IdP verifies the authenticity of the SAML request.

For such requests, you attach the X.509 certificate along with a signed signature to the request. When the IdP receives the request, it will verify that it actually came from you by decrypting the signature using the public key on the X.509 certificate and confirming that the hash values match. 

As you can see, generating the certificate is a tedious process. An easier way is to use the WorkOS Admin Portal.

How to get an X.509 certificate (the easy way)

WorkOS has built flows in order to minimize this process to make it as smooth as possible to keep certificate active at all times. During set up, the WorkOS Admin Portal flow will encourage your customers to upload metadata URLs and allow WorkOS to automatically handle the transition to new certificates with no downtime. This way when WorkOS updates the metadata, such as refreshing an expiring X.509 certificate, the IdP will automatically use the new certificate. Zero downtime and zero manual intervention.

However, if your customers do choose to manually upload their certificates, the dashboard has built in advanced filtering and alerts to keep you on top of expiring and expired certificates. You will also receive notifications through email, or Slack about upcoming customer expiries to make sure that you're always on top of any situation. Connections that have expiring or expired certificates will also allow you to create a new Admin Portal intent for certificate renewal that can be shared directly with admins. These can be emailed to your IT admins directly through WorkOS, or links can be manually shared. WorkOS can check for multiple active certificates for a connection so there's zero downtime.

Next steps

X.509 certificates are crucial for secure communications and are not the only security feature that WorkOS supports. With just a single integration API, you can integrate SSO in your app for all the major identity providers (such as Microsoft Entra ID and Okta) using other protocols like SAML SSO and OIDC.

• Get started fast: With SDKs in every popular language, easy-to-follow documentation, and Slack-based support, you can implement SSO in minutes rather than weeks.
• Support every protocol: With OAuth 2.0 integrations to popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML/OIDC connections, WorkOS can support any enterprise customer.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they bring 10 or 10,000 SSO users to your app.

Explore Unified SSO by WorkOS.