What is an SSL/TLS certificate?

An SSL/TLS certificate is a small digital file that enables websites to prove to clients that they control a given set of domain names and content, over an HTTPS connection. As part of the service’s public key infrastructure (PKI), SSL/TLS certificates have become essential components that enable safer browsing without noticeably impacting performance. They also enable authentication between the browser and origin server to ensure secure traffic reaches the correct destination.

History of SSL/TLS certificates

Organizations can obtain SSL/TLS certificates (and often for free) through vendors called certificate authorities (CAs). Since Verisign’s 1995 debut as the web’s first public CA, many other issuers have driven SSL/TLS adoption for hundreds of millions of websites worldwide. Application delivery platforms like HAProxy One have taken this a step further by adding integrations for popular authorities, such as Let’s Encrypt.

Multiple versions of the SSL protocol have also come and gone, with TLS launching as a more secure successor in 1999. SSL/TLS certificate vendors have evolved along the way to account for these new advancements in encryption. According to Google’s 2025 Transparency Report, over 90% of websites serve content over HTTPS. That proportion is likely even higher today.

How do SSL/TLS certificates work?

SSL/TLS certificates from trusted third parties are installed within the web browser, and share their public encryption key. These keys are made up of randomized numeric strings according to the encryption method the issuer uses to form a secure HTTPS connection, such as ECDSA (Elliptic Curve Digital Signature Algorithm) or RSA (Rivest–Shamir–Adleman). Hashing algorithms such as SHA-256 allow one certificate to authenticate another certificate, forming a chain of trust to a verified certificate authority.

Certificate encryption algorithms are always asymmetric. The certificate issuer uses a public key to encrypt data and its own private key (stored exclusively on the web server) for decryption. This allows the web server to mathematically prove it owns the SSL/TLS certificate and helps prevent man-in-the-middle (MITM) attacks.

During the TLS handshake, the client and server agree on an encryption key. This will be used for the duration of the connection, yet immune to tampering from anyone watching the traffic. This key is used for the cipher negotiated during the TLS handshake, often AES_256_GCM_SHA384 for modern clients. Such a cipher uses the Advanced Encryption Standard algorithm with a 256 bit key in GCM mode. Meanwhile, the accompanying Secure Hash Algorithm uses a 384 bit authentication key.

What does an SSL/TLS certificate contain?

Determining whether or not a website uses a secure connection is pretty simple. Just look for the padlock icon in the address bar, which may require you to expand the URL. A secure URL will always begin with https://, which users can confirm by clicking within the address bar and inspecting the link.

Viewing an HTTPS website’s digital certificate is also pretty easy. The browser has these details readily available for each applicable website, either through the address bar or a top-level menu option.

Upon expanding this pop-up, you’ll see that an SSL/TLS certificate typically contains the following information:

• Supported domain and subdomain names

• The issuing certificate authority (CA), including the root certificate issuer and intermediary certificate authority (if applicable)

• An expiration date and a “not valid before” date

• The certificate’s status (is it valid or not)

• Signature algorithm (such as SHA-256 with RSA encryption)

• Public key information (including algorithm, special parameters, key size, and usage)

• Timestamps, fingerprint data, and more

These details will change with each website you visit. Connection security details can get pretty granular, but can help administrators better understand exactly how their data is protected. This setup builds trust through transparency. Plus, private key details will always be absent because the client doesn’t know them. The certificate’s private key is only known by the web servers, and only signing authorities will know the key for the certificates higher in the chain.

Can you create your own SSL/TLS certificate?

It’s possible to make one’s own certificate authority and certificates, and only clients who’ve added the custom CA certificate to their trust stores will trust it. Next, we have self-signed certificates, which are even easier to create. In this case, the website signs its certificate using its own private key instead of using an external private key.

While this brings convenience and possibly cost savings to the website, most browsers still treat self-signed certificates with higher skepticism. Without public key verification, a man-in-the-middle (MITM) attack is easy for anyone with control over a client’s network connection. These domains aren’t trustworthy and lack the HTTPS designation, or more commonly show https crossed out in red within the browser’s address bar. They also risk being blocked. 

Corporate policy may not allow bypassing certificate warnings, and the browser will reject the connection if it’s previously seen a strict-transport-security header for that specific domain. For this reason, critical services should choose certificates provided through a legitimate certificate authority.

What are the benefits of SSL/TLS certificates?

Websites gain the following advantages by using trusted digital certificates:

• They’re capable of using HTTPS and are considered safer for users, ensuring information sent and received hasn’t been modified nor read by third parties.

• They’re viewed as more authoritative and legitimate than websites without them.

• They typically rank higher on Google’s search engine results page (SERP) since HTTPS is now the expected standard.

• They’re more compliant with regulatory guidelines, and especially in sensitive industries.

Companies and websites that fail to implement SSL/TLS are generally viewed less favorably. Remember that encryption also isn’t “free” in most cases, as it incurs some processing overhead at the web server, and can add some amount of network latency.

Since most CPUs have added extensions that perform hardware-based AES encryption and decryption, this cost is mostly incurred during the handshake. During this process, the client and server calculate which encryption and authentication they’ll use. However, these trade-offs are worthwhile for organizations looking to protect themselves and their users.

Does HAProxy support SSL/TLS certificates?

Yes. HAProxy handles SSL/TLS certificates at the proxy layer, taking on the TLS handshake so your backend servers don’t have to. It supports end-to-end encryption, mutual TLS (mTLS) for client authentication, and ACME protocol integration with providers like Let’s Encrypt for automated issuance and renewal.

HAProxy One, the world’s fastest application delivery and security platform, extends this with certificate management at scale through HAProxy Fusion, ACL-based routing that reads SSL/TLS data, and AWS-LC integration that delivers up to 2x higher cryptographic performance compared to OpenSSL.

See how HAProxy offloads encryption from your backend servers with our SSL/TLS termination solution, then request a demo to test certificate automation in your own environment.

FAQs