Enter any HTTPS URL to inspect its SSL/TLS certificate and view the complete chain of trust
Check SSL/TLS certificates for any website with our free certificate chain viewer. Verify certificate validity, expiration dates, issuing authority, and view the complete certificate chain from root to leaf certificate. Essential for security audits, troubleshooting HTTPS issues, and ensuring proper SSL/TLS configuration.
An SSL/TLS certificate is a digital document that authenticates a website's identity and enables encrypted connections. When you visit a website using HTTPS, the SSL/TLS certificate ensures you're connecting to the legitimate site and that data transmitted between your browser and the server is encrypted. Certificates are issued by trusted Certificate Authorities (CAs) and contain information about the website owner, validity period, and cryptographic keys used for encryption.
A certificate chain (also called chain of trust) is a hierarchical sequence of certificates linking your website's certificate to a trusted root certificate. The chain typically contains three levels: the leaf certificate (your website), one or more intermediate certificates, and a root certificate. Browsers trust root certificates from known Certificate Authorities, and this trust extends down the chain to validate your website's certificate.
The leaf certificate is issued directly to your website and contains your domain name, public key, and validity period. This is the certificate users' browsers validate when connecting to your site. It's signed by an intermediate certificate, proving its authenticity. Leaf certificates have the shortest validity period (typically 90 days to 1 year) and must be renewed regularly. They contain Subject Alternative Names (SANs) listing all domains the certificate covers.
Intermediate certificates sit between leaf and root certificates, providing additional security through certificate authority delegation. CAs use intermediates to sign leaf certificates while keeping root certificates offline and secure. If an intermediate certificate is compromised, only certificates signed by that intermediate need revocation, not the entire root. Websites must provide intermediate certificates to browsers for proper chain validation - missing intermediates cause connection errors.
Root certificates are self-signed certificates from trusted Certificate Authorities pre-installed in operating systems and browsers. These represent the ultimate trust anchors in the certificate chain. Root CAs guard their private keys extremely carefully since compromise would affect millions of websites. Browsers and operating systems maintain lists of trusted root certificates through security updates. Websites don't need to provide root certificates as browsers already have them installed.
Expired certificates cause browsers to display security warnings blocking website access. Certificate expiration is a common cause of website outages, especially with modern short validity periods (90-365 days). Automated certificate renewal through Let's Encrypt or ACME protocols prevents expiration issues. Monitor certificates and renew them at least 30 days before expiration. Some organizations use certificate monitoring services that alert administrators about upcoming expirations.
Missing intermediate certificates cause browsers to fail validation even though the leaf certificate is valid. This occurs when servers don't send the complete chain to browsers. Users see errors like "unable to get local issuer certificate" or "certificate chain incomplete." Server administrators must configure web servers to send both leaf and intermediate certificates. Most certificate providers supply a bundle file containing the complete chain for server configuration.
Hostname mismatch errors occur when the domain in the certificate doesn't match the website address. If a certificate is issued for example.com but users visit www.example.com, browsers show warnings. Certificates should include all domain variations in Subject Alternative Names (SANs). Wildcard certificates (*.example.com) cover all subdomains but not the root domain itself. Always verify SANs include all domains users might access.
Self-signed certificates aren't issued by trusted Certificate Authorities, causing browser warnings. They're appropriate for internal testing or development but should never be used in production for public websites. Browsers don't trust self-signed certificates since there's no third-party verification of identity. For internal systems, organizations can deploy their own root certificate to employee devices, making internal self-signed certificates trusted within the organization.
When connecting to an HTTPS website, browsers perform multiple validation checks. First, they verify the certificate chain links to a trusted root. Next, they check the certificate isn't expired and covers the requested domain. Browsers also verify the certificate hasn't been revoked through CRL (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol). Finally, they validate cryptographic signatures ensuring certificates haven't been tampered with. All checks must pass for a successful connection.
Revoked certificates are no longer trustworthy even if not yet expired. Revocation occurs when private keys are compromised, domain ownership changes, or certificates are issued incorrectly. Certificate Authorities maintain Certificate Revocation Lists (CRLs) and OCSP responders for revocation checking. Modern browsers use OCSP stapling where servers prove certificate validity, reducing latency. Some browsers have moved to CRLSets - pre-compiled lists of revoked certificates distributed through browser updates.
Extended Validation certificates require rigorous identity verification before issuance, historically displaying company names in the browser address bar. However, major browsers have removed the prominent EV indicator, reducing the practical value of expensive EV certificates. Domain Validation (DV) and Organization Validation (OV) certificates now provide similar security with faster issuance and lower cost. Modern security practices focus on certificate management automation rather than validation level.
TLS 1.3 is the latest and most secure version, offering faster handshakes and improved security. It removes support for weak cryptographic algorithms and vulnerable features from earlier versions. TLS 1.3 reduces connection latency through zero-round-trip-time (0-RTT) resumption for repeat connections. All modern browsers and servers support TLS 1.3. Organizations should enable TLS 1.3 and disable older versions for maximum security. However, legacy system compatibility sometimes requires supporting TLS 1.2.
TLS 1.2 remains widely deployed and secure when properly configured with strong cipher suites. While TLS 1.3 is preferred, TLS 1.2 provides adequate security for systems that cannot upgrade. Organizations supporting TLS 1.2 should disable weak ciphers, enable forward secrecy, and prefer AEAD cipher suites. Many compliance frameworks still accept TLS 1.2. Security best practices recommend supporting both TLS 1.2 and 1.3 for broad compatibility while maintaining security.
SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 have known vulnerabilities and should never be used. Major browsers have disabled these protocols completely. Systems still using deprecated protocols are vulnerable to attacks like POODLE, BEAST, and CRIME. PCI DSS and other compliance standards prohibit deprecated protocols. Organizations must upgrade systems using old protocols - there are no workarounds or exceptions for security-critical applications.
Public CAs like Let's Encrypt, DigiCert, Sectigo, and GlobalSign issue certificates trusted by all major browsers and operating systems. Let's Encrypt revolutionized certificate issuance by providing free automated certificates with 90-day validity, encouraging frequent renewal. Commercial CAs offer additional services like extended support, insurance, and organization validation. Choosing a CA depends on automation capabilities, support requirements, and validation level needs.
Let's Encrypt is a free, automated Certificate Authority providing domain-validated certificates. The ACME protocol enables fully automated certificate issuance and renewal, eliminating manual processes. Let's Encrypt issues over 200 million certificates and has made HTTPS accessible to everyone. The 90-day validity period encourages automation and limits impact from compromise. All major hosting providers and web servers support Let's Encrypt integration. Organizations using Let's Encrypt must implement automated renewal to prevent expiration.
Organizations can operate internal Certificate Authorities for private networks and services. Private CAs work well for internal applications, development environments, and IoT devices that never face the public internet. Deploying the root certificate to all organization devices establishes trust. Private CAs provide full control over certificate policies and don't require internet connectivity. However, they require significant infrastructure and expertise to operate securely. Never use private CA certificates for public-facing websites.
Certificate expiration is a leading cause of website outages. Automated renewal through ACME clients like Certbot, acme.sh, or built-in hosting features prevents expiration issues. Configure renewal to run daily, attempting renewal when certificates have 30 days remaining. Monitor renewal processes and set up alerts for failures. Test renewal in staging environments before production deployment. Automation eliminates human error and ensures certificates remain valid.
Implement certificate monitoring to track expiration dates, detect issues, and receive alerts. Monitor not just leaf certificates but the entire chain including intermediates. Services like SSL Labs, Certificate Transparency logs, and dedicated monitoring tools provide visibility. Set alerts for certificates expiring within 30, 14, and 7 days. Monitor revocation status and check for weak configurations. Regular monitoring prevents surprises and enables proactive management.
Private keys must be protected with the same rigor as passwords for privileged accounts. Store private keys with restricted file permissions on secure systems. Never commit keys to version control or share them via insecure channels. Use hardware security modules (HSMs) for high-value certificates. Generate new keys for each certificate rather than reusing keys. If a private key is compromised, immediately revoke the certificate and generate a new key pair.
Configure servers to support only TLS 1.2 and 1.3 with strong cipher suites. Disable weak ciphers, export-grade encryption, and algorithms with known vulnerabilities. Enable forward secrecy through ECDHE or DHE key exchange. Prefer AEAD cipher suites like AES-GCM or ChaCha20-Poly1305. Use tools like SSL Labs Server Test to verify configuration. Regular audits ensure configurations remain secure as new vulnerabilities emerge.
"Certificate has expired" means the validity period has passed - renew the certificate immediately. "Certificate not trusted" indicates the chain doesn't link to a trusted root - check intermediate certificates. "Hostname mismatch" means the domain isn't in the certificate's SANs - reissue with correct domains. "Unable to get issuer certificate" suggests missing intermediates - provide the complete chain. Understanding error messages helps diagnose and resolve issues quickly.
Online certificate checkers like this tool, SSL Labs, and DigiCert provide detailed analysis without requiring server access. These tools show certificate details, chain validation, protocol support, and security issues. They're essential for diagnosing user-reported errors from external perspectives. Check certificates from multiple tools and locations to identify geographically-specific or intermittent issues. Regular checks as part of routine maintenance catch problems before users do.
Browser developer tools provide certificate inspection capabilities. In Chrome/Edge, click the padlock icon and select "Certificate" to view details. Firefox offers similar functionality. Developer tools show the certificate chain, validity dates, and trust status from the browser's perspective. This helps diagnose client-side issues versus server configuration problems. Network panels show TLS version and cipher suite used for connections.
Modern best practices recommend automating renewal at 30 days before expiration. Let's Encrypt certificates expire every 90 days, requiring frequent renewal. Longer-validity certificates from commercial CAs should still be renewed early to minimize expiration risk. Automated renewal removes manual processes prone to error. Never wait until the last minute - system failures or process issues may delay renewal.
Domain Validation (DV) certificates verify only domain control through automated checks - fastest and cheapest. Organization Validation (OV) requires business verification documentation - takes days and costs more. Extended Validation (EV) involves rigorous identity verification - most expensive but browsers no longer prominently display EV status. For most use cases, DV certificates from Let's Encrypt or commercial providers provide adequate security. OV or EV make sense primarily for large enterprises with specific compliance requirements.
Yes, certificates can be deployed to multiple servers if all servers host the same domains listed in the certificate. However, the private key must also be copied to each server, increasing risk of key exposure. For high-security environments, consider separate certificates for each server or load balancer. Wildcard or multi-domain certificates enable sharing across many servers. Always protect private keys during transfer and storage.
Subject Alternative Names list all domains and subdomains covered by a certificate. Modern certificates require SANs even for the primary domain. SANs enable one certificate to secure multiple hostnames like example.com, www.example.com, and api.example.com. Wildcard SANs (*.example.com) cover all subdomains but not the root domain. Always verify SANs include all domains users might access to avoid hostname mismatch errors.
Browser warnings indicate certificate validation failures. Common causes include expired certificates, incomplete chains, hostname mismatches, revoked certificates, or self-signed certificates. Warnings protect users from potentially malicious sites or misconfigured servers. Never bypass warnings on financial or sensitive sites. For your own sites, investigate and fix certificate issues immediately as warnings severely impact user trust and conversions.
Use this tool or SSL Labs to check certificate expiration dates. Command-line tools like OpenSSL can also check: `openssl s_client -connect example.com:443 | openssl x509 -noout -dates`. Set up automated monitoring with services like UptimeRobot, StatusCake, or certificate-specific monitoring tools. Most certificate providers send expiration reminder emails, but don't rely solely on these - implement independent monitoring and automated renewal.