LumaProbe opens a verified TLS connection to the public hostname on port 443 and reads the certificate presented by that server. Private destinations, credentials and non-standard ports are blocked.
A successful check confirms that this server could validate the certificate chain and hostname at that moment. It does not test every TLS version, cipher, browser trust store or application path.
The checker validates an ASCII public hostname, resolves its public addresses and pins one validated address for a TLS connection on port 443. PHP OpenSSL verifies the certificate chain and hostname using the server trust store while Server Name Indication requests the certificate for the entered host.
After a successful handshake, LumaProbe parses the leaf certificate to show its subject, issuer, start and expiry times, remaining days, SHA-256 fingerprint and a limited list of covered DNS names. The raw certificate and private keys are never requested or stored.
Enter the exact hostname visitors use, such as www.example.com, without https://, a path or a port. The apex and www hostnames can present different certificates. Do not enter a private server name, control-panel address or link containing a login token.
If diagnosing a warning, record the browser’s exact message and time before checking. Certificate renewal may have completed on one load balancer while another still serves an older chain, so repeat after DNS or deployment changes have reached all intended endpoints.
A verified result means this server completed a trusted TLS handshake and the certificate covered the requested hostname at that moment. Days remaining helps identify an approaching expiry; covered names show which DNS identities the leaf certificate advertises. A fingerprint identifies the exact certificate and is useful when comparing endpoints.
A failed result may come from expiry, a name mismatch, an incomplete chain, an untrusted issuer, a blocked connection or a server that does not speak TLS on port 443. The deliberately generic error avoids treating every handshake failure as the same certificate fault.
This is not a vulnerability scanner. It does not enumerate old protocol versions, every cipher, OCSP behaviour, Certificate Transparency logs, application redirects or mixed content. Trust stores also vary between operating systems, browsers and enterprise devices, so one verified result cannot guarantee universal compatibility.
The check originates from one server and examines one resolved public address. Large sites can present different certificates by region or edge. Use the hosting provider’s tools and independent multi-region checks when a certificate protects a critical service.
If expiry is near, renew through the actual hosting platform or certificate authority and confirm that the new certificate is assigned to the correct virtual host. Keep automatic renewal enabled where supported, but also verify that the web server reloads the renewed files.
For a failed handshake, confirm DNS first, then certificate name, chain and server assignment. Never bypass a certificate warning on an administration or payment page merely because a separate checker returned partial information.
Read the complete LumaProbe test methodology and privacy notes →
This server completed a trusted TLS connection to port 443 and the certificate covered the entered hostname at that moment.
No. It checks certificate trust, identity and dates, not every protocol version, cipher, revocation mechanism or application vulnerability.
Browsers and operating systems use different trust stores, while large sites can present different certificates by region or edge. Check the exact browser message and hostname.