While SSL certificates are most visibly associated with securing websites, they are used far more broadly than that. API gateways, email servers, VPN endpoints, load balancers, microservices, IoT devices, and internal service-to-service connections all rely on SSL/TLS certificates to authenticate and encrypt communication.
SSL certificates are issued by trusted third-party organizations called certificate authorities (CAs). The CA validates the identity of the certificate applicant and signs the certificate, and in doing so establishes the trust chain that clients rely on to determine whether a connection can be trusted. Certificates are a core component of public key infrastructure, the broader framework that governs how digital identities are verified and how encrypted communication is established at scale.
Key takeaways
- What SSL certificates do: SSL/TLS certificates authenticate servers and encrypt communication. They are foundational to any secure connection, whether it is a website, API, or internal service.
- Types and scope: Certificate types vary by validation level (domain-validated, organization-validated, and extended validation) and domain coverage (single, multi-domain, and wildcard). Choose based on what you are securing and how much trust you need to convey.
- Validity and automation: Certificates expire, and the industry is moving toward 47-day validity by 2029. Manual renewal processes do not scale; automation is essential.
What does an SSL certificate do?
At a functional level, an SSL certificate does two things simultaneously; both are essential for any communication channel that needs to be secure, whether that is a browser connecting to a website, an API calling another service, or a device authenticating to a management platform.
- 01.
Identity verification
The certificate proves that the server or endpoint a client is connecting to is actually who it claims to be. Without this, there is no way for a client to distinguish a legitimate server from a malicious one impersonating it. This verification is what prevents manipulator-in-the-middle attacks, where an attacker intercepts traffic by pretending to be the destination server. The certificate's digital signature, traceable back through the chain of trust to a trusted root CA, is what makes this verification possible. In browser-to-server communication, this is what gives users confidence the site is legitimate. In machine-to-machine communication, this is what ensures that services, APIs, and devices are talking to the right counterpart and not an imposter.
- 02.
Encryption
Once the identity is verified and the connection is established, the certificate enables encryption of all data exchanged during the session. For web traffic, this means login credentials, payment information, and personal data. For back-end and infrastructure communication, this means API payloads, database queries, inter-service messages, and any other data moving between systems. The encryption uses a combination of asymmetric encryption (during the initial handshake) and symmetric encryption (for the session itself), with the certificate's public key playing a central role in setting up the secure channel.
Together, these two functions are what make HTTPS possible for websites and what make TLS-secured connections possible across every other layer of an organization's infrastructure. A server or endpoint without a valid SSL/TLS certificate cannot establish an authenticated, encrypted connection, and clients, whether browsers or other services, will either reject the connection or proceed without the protections that the certificate provides.
What information is inside an SSL certificate?
An SSL certificate is essentially a structured data file that follows the X.509 standard. When a client connects to a server and receives the certificate, it reads this data to determine whether the connection can be trusted. Here is what a typical certificate contains:
- 01.
Subject
The identity of the entity the certificate was issued to. For a website certificate, this is the domain name (e.g., yourdomain.com). For organization-validated and extended validation certificates, it also includes organizational details like the company name, city, state, and country.
- 02.
Issuer
The CA that issued and signed the certificate. This is how the client traces the certificate back through the trust chain to determine whether it was issued by a CA it recognizes.
- 03.
Public key
The server's public key, along with the algorithm used to generate it (typically RSA or ECDSA). This key is used during the SSL/TLS handshake to establish the encrypted session.
- 04.
Validity period
The dates that define when the certificate is valid. Outside this window, the certificate is considered expired or not yet active, and clients will reject the connection.
- 05.
Serial number
A unique identifier assigned by the CA. This is used to track and manage the certificate, and it is referenced during revocation checks.
- 06.
Signature algorithm
The cryptographic algorithm the CA used to sign the certificate (e.g., SHA-256 with RSA). The client uses this to verify that the certificate has not been tampered with.
- 07.
Subject alternative names
Additional domain names or subdomains that the certificate covers beyond the primary subject. Multi-domain certificates rely on subject alternative names (SANs) to secure multiple domains under a single certificate.
- 08.
Certificate revocation information
Pointers to the CA's certificate revocation list or OCSP responder, which the client can check to confirm the certificate has not been revoked before its expiry date.
All of this information is encoded into the certificate file, and clients process it automatically during the handshake. For website certificates, users can view it manually by clicking the padlock icon in the browser's address bar.
How does SSL work?
When a client attempts to connect to a server over a TLS-secured channel, both communicating parties validate one another's identity through a series of steps before establishing a connection and exchanging data. This process is called an SSL/TLS handshake. It is also during this process that a session key is generated, which provides symmetric encryption of the particular session after both parties have successfully authenticated one another. The same handshake process applies whether the client is a web browser, an API consumer, a mobile application, or any other service initiating a TLS connection.
Listed below is the sequence of steps that take place in the background during an SSL/TLS handshake:
- 01.
Client hello
The client sends the server a request to establish a connection, including a list of its compatible cipher suites and SSL/TLS versions.
- 02.
Server hello
The server receives the request, checks the cipher suites and SSL/TLS versions, and chooses a mutually compatible cipher suite and version from the list. The server also sends its certificate along with the public key.
- 03.
Generation of pre-master key
The client receives the certificate, extracts the public key, creates a new key called the pre-master key, and sends it to the server.
- 04.
Decryption of the pre-master key
The server decrypts the pre-master key using its private key.
- 05.
Generation of the shared secret
Both the server and client now use the pre-master key and compute a shared secret called the session key (symmetrical encryption key).
- 06.
Client verification
The client sends a test message that is encrypted with the session key to the server.
- 07.
Server acknowledgement
The server receives the message, decrypts it using the session key, and sends an acknowledgement that is also encrypted using the session key back to the client, requesting to initiate the session.
- 08.
Connection establishment
The session begins, and both the client and server use the session key to encrypt their communication during the rest of the session.
The difference between SSL and TLS certificates
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are both cryptographic protocols designed to secure communication between a client and a server, but they are not the same thing. SSL is the older protocol, originally developed by Netscape in the mid-1990s. TLS is its successor, first introduced in 1999 as an upgrade that addressed known vulnerabilities in SSL and improved the handshake process, encryption mechanisms, and overall security.
Every version of SSL (including SSL 3.0) is now considered insecure and has been formally deprecated. Modern web communication runs on TLS, with TLS 1.2 and TLS 1.3 being the current standards. TLS 1.3, the latest version, streamlines the handshake process (reducing it from two round-trips to one), removes support for weaker cipher suites, and provides better performance alongside stronger security.
Despite this, the industry still widely uses the term SSL certificate out of convention. When someone refers to an SSL certificate today, they are almost always talking about a certificate used in a TLS connection. The certificate itself is not SSL-specific or TLS-specific; it is the same X.509 certificate regardless of which protocol version is being used. What differs is the protocol the server is configured to support.
For a more detailed breakdown, see our SSL versus TLS comparison.
Why are SSL certificates important?
SSL/TLS certificates are the mechanism that makes encrypted, authenticated communication possible across digital infrastructure. For websites, they let users know the connection is secure and their data is protected. For everything behind the website, including the APIs, microservices, email servers, VPN tunnels, cloud workloads, and internal applications, they serve the same function: verifying identity and encrypting data in transit so that nothing is exposed or tampered with.
The importance goes beyond just the technical security layer. Modern browsers actively flag HTTP sites with security warnings, which erodes user trust and can drive visitors away before they engage with the content. Google has used HTTPS as a ranking signal since 2014, meaning sites with valid certificates have an advantage in search results. And for enterprise environments, SSL/TLS certificates are a compliance requirement under frameworks like the PCI DSS, HIPAA, and SOC 2, which mandate encrypted transmission of sensitive data. An expired or misconfigured certificate does not just break a connection; it can trigger a compliance violation, take down a production service, or expose sensitive data to interception.
For any organization that handles user data, processes transactions, runs internal services, or connects systems to each other, SSL/TLS certificates are foundational infrastructure, not an optional enhancement.
Types of SSL certificates
SSL certificates vary along two dimensions: the level of identity validation the CA performs before issuing the certificate, and how many domains or subdomains the certificate covers. Understanding both is important because they determine the level of trust the certificate conveys and the operational scope it supports.
- 01.
By validation level
Organization-validated certificates
Organization-validated (OV) certificates go a step further by verifying the identity of the organization requesting the certificate. The CA checks business registration details and confirms that the organization legally exists and controls the domain. This provides a higher level of assurance to visitors, and the organizational details are visible in the certificate when inspected. OV certificates are commonly used by businesses, institutions, and organizations that want to convey legitimacy beyond just domain ownership.
Extended validation certificates
Extended validation (EV) certificates involve the most rigorous validation process. The CA verifies the legal, physical, and operational existence of the organization according to guidelines set by the CA/Browser Forum. EV certificates are used by banks, major e-commerce platforms, and other organizations where establishing immediate, visible trust with end users is critical.
- 02.
By domain coverage
Single-domain certificates
These certificates secure one fully qualified domain name. A certificate issued for www.yourdomain.com covers that specific domain and its pages but nothing else. Single-domain certificates are straightforward and appropriate for organizations managing a single website or application.Multi-domain (SAN) certificates
Multi-domain certificates use SANs to secure multiple distinct domains, subdomains, or IP addresses under a single certificate. A single multi-domain certificate could cover yourdomain.com, app.yourdomain.com, and anotherdomain.com simultaneously. These are useful for organizations managing several properties and looking to simplify certificate operations.
Wildcard certificates
Wildcard certificates secure a primary domain and all of its subdomains at one level. A wildcard certificate for *.yourdomain.com would cover mail.yourdomain.com, shop.yourdomain.com, blog.yourdomain.com, and any other subdomain under that top-level domain. The trade-off is that if the certificate needs to be revoked, the revocation affects every subdomain it covers.
What type of SSL certificate do I need?
The right certificate depends on what you are securing, how much organizational trust you need to convey, and how many domains are in scope. Here is a practical way to think about it:
If you are running a personal site, blog, or small project where the primary goal is encryption and you do not need to verify organizational identity, a DV certificate is the simplest and most cost-effective option. Let's Encrypt offers free DV certificates with automated issuance and renewal, making them a popular choice for straightforward use cases.
If you are running a business-facing website or application where users expect to see that a verified organization is behind the site, particularly if you are collecting personal information, processing forms, or handling account logins, an OV certificate provides the additional assurance. Visitors who inspect the certificate can see the organization's verified details, which helps build trust.
If you operate in a high-trust environment like banking, financial services, e-commerce, or healthcare, and establishing maximum visible credibility is important, an EV certificate makes sense. The EV process is more involved and takes longer to complete, but it provides the highest level of identity assurance available.
For domain coverage, the choice is simpler. If you have a single domain, use a single-domain certificate. If you manage multiple distinct domains, use a multi-domain (SAN) certificate. If you have one domain with many subdomains, a wildcard certificate reduces management overhead. Many organizations with complex environments use a combination of these across their certificate estate.
How do you get an SSL certificate?
The process for obtaining an SSL certificate follows a standard sequence, regardless of which CA you choose or what type of certificate you need.
- 01.
Generate a certificate signing request
The process starts on the server where the certificate will be installed. You generate a certificate signing request (CSR), which is an encoded file containing your organization's details and the server's public key. The CSR also creates the private key, which stays on your server and is never shared.
- 02.
Submit the CSR to a CA
Send the CSR to the CA you have chosen. The CA uses the information in the CSR to begin the validation process for the certificate type you requested.
- 03.
Complete the validation process
For DV certificates, this is typically automated: The CA may ask you to add a DNS record, respond to an email sent to the domain's admin address, or place a specific file on your web server. For OV and EV certificates, the CA will also verify your organizational identity through business documentation, registration records, and sometimes a phone call.
- 04.
Receive and install the certificate
Once validation is complete, the CA issues the certificate. You then install it on your server along with any intermediate certificates required to complete the chain of trust. The installation process varies depending on the server type (Apache, Nginx, IIS, etc.).
- 05.
Verify the installation
After installation, test the certificate to confirm it is configured correctly, the trust chain is intact, and there are no vulnerabilities. Post-deployment scans can catch misconfigured certificates, missing intermediates, and weak cipher suites before they become a problem in production.
How long do SSL/TLS certificates last?
Every SSL/TLS certificate has a defined validity period, and when it expires, the certificate is no longer trusted by clients. For websites, the browser will display a warning to the user, and depending on the browser's configuration, may block access to the site entirely. For APIs, services, and machine-to-machine connections, an expired certificate typically means a hard failure: The connection is refused, and whatever depends on it stops working. An expired certificate breaks the encrypted connection and can take down services, APIs, and application integrations that depend on it.
The maximum validity period for publicly trusted SSL/TLS certificates has been steadily shrinking over the years. It moved from five years to three, then to two, then to 398 days (roughly 13 months) in 2020, and now 200 days since Mar. 15, 2026. The trajectory is continuing: The CA/Browser Forum has approved a ballot to reduce maximum certificate validity to 100 days by March 2027, and ultimately to 47 days by March 2029.
The logic behind shorter lifetimes is that they reduce the exposure window if a certificate or its private key is compromised, they force more frequent revalidation of domain ownership, and they push the industry toward automated certificate management. But the operational reality is that each reduction multiplies the number of renewal events an organization has to handle. An environment with 500 certificates on annual validity has 500 renewals a year. At 47-day validity, that same estate generates roughly 4,000 renewal events annually. Without automation, that volume is unmanageable.
Common SSL certificate issues you should know about
Even properly issued SSL certificates can cause problems if they are not managed correctly. These issues affect websites, APIs, internal services, and machine-to-machine connections alike, and most of them are preventable.
- 01.
Expired certificates
This is the single most common SSL-related issue, and it is almost always a process failure rather than a technical one. Someone loses track of the expiry date, the renewal reminder goes to a mailbox nobody monitors, or the person who originally set up the certificate has left the organization. The result is a broken connection, and depending on where the certificate lives, that could mean a browser warning on a public website, a failed API integration between services, or an internal application going offline. Prevention comes down to centralized tracking and automated renewal workflows that do not depend on a single person remembering to act.
- 02.
Incomplete certificate chains
When a server presents its certificate to a client, it also needs to present any intermediate certificates that link it back to the trusted root CA. If the intermediates are missing, the client cannot verify the trust chain and will either warn the user (in the case of a browser) or reject the connection outright (in the case of an API client or service). This happens most often during manual installations where the intermediate certificates were not included in the deployment. Testing the installation with an SSL checker tool after deployment catches this immediately.
- 03.
Certificate-domain mismatch
If the hostname the client is connecting to does not match the domain (or SANs) on the certificate, the connection will be flagged or rejected. For websites, this happens when a certificate is installed on the wrong server, or when the certificate was issued for www.yourdomain.com but the user accesses yourdomain.com without the www. For internal services and APIs, it happens when certificates are issued with hostnames that do not match the DNS entries or service endpoints they are deployed to. Getting the domain names and SANs right during the CSR generation step avoids this.
- 04.
Weak encryption or deprecated protocols
Certificates installed on servers that still support deprecated protocol versions (like SSL 3.0, TLS 1.0, or TLS 1.1) or weak cipher suites are vulnerable even if the certificate itself is valid. The certificate is only as strong as the protocol and encryption configuration on the server. Regular vulnerability scans and keeping server configurations aligned with current TLS best practices are the fix.
- 05.
Revoked certificates still in use
If a certificate's private key is compromised or the certificate was mis-issued, the CA revokes it. But revocation does not automatically remove the certificate from the server where it is installed. If the revoked certificate is not replaced, users may encounter trust errors, and the server remains exposed. Organizations need revocation monitoring alongside their expiry monitoring to catch this.
- 06.
Self-signed certificates on public-facing services
Self-signed certificates are useful for internal testing and development environments, but they are not trusted by browsers and will trigger warnings when used on public-facing sites. Organizations sometimes deploy self-signed certificates as a quick fix and forget to replace them with CA-signed certificates, which erodes user trust and signals to visitors that the site may not be safe.
When you need centralized SSL certificate life cycle management
If your organization manages five certificates across one or two servers, manual tracking will probably get the job done. But most enterprise environments are well past that point. Certificates are spread across web servers, load balancers, API gateways, email platforms, cloud services, and internal applications; issued by different CAs; managed by different teams; and all have their own expiry dates and renewal workflows.
Once you reach the point where keeping track of what you have, what is expiring, who owns it, and which CA issued it requires more than a spreadsheet, you need a centralized approach. And with certificate validity periods heading toward 47 days, even organizations that are managing the current volume comfortably are going to hit a wall when the renewal frequency multiplies.
How Key Manager Plus helps manage SSL certificates at scale
ManageEngine Key Manager Plus is built to do this. It gives security and IT teams a single interface to manage the entire certificate life cycle across their environment. Automated certificate discovery scans your network, cloud environments, and CA databases continuously, so you are working from a complete, up-to-date inventory rather than guessing at what exists. Expiry tracking and alerting are built in, with configurable notification windows so the right people know about upcoming renewals before they become emergencies. End-to-end life cycle workflows cover CSR generation, CA submission, certificate renewal and deployment, with automation that removes manual intervention from the routine operations. And because most enterprises work with all major public CAs, alongside MSCA and other private CA certificates, Key Manager Plus unifies all of that into a single operational workflow with full audit trails for all certificate operations.