TLS Certificate Checker

Controleer het TLS/SSL-certificaat van een site: onderwerp/uitgever, geldigheidsdatums, SAN's, ketencompleetheid en veelvoorkomende HTTPS-misconfiguraties. Volg optioneel omleidingen om te verifiëren dat de eindbestemming HTTPS is met een geldig certificaat. Exporteer JSON/PDF-rapporten.

Loading…

Over TLS Certificaat Checker

Wanneer HTTPS faalt, zien gebruikers enge waarschuwingen en stoppen bots met het vertrouwen van je site. Deze tool haalt een URL op, volgt optioneel omleidingen en inspecteert het TLS-certificaat dat het uiteindelijke HTTPS-eindpunt beschermt. Het helpt je bij het opsporen van verlopen certificaten, onvolledige ketens, hostname/SAN-mismatches en andere problemen die vaak browserfouten en SEO/beschikbaarheidsproblemen veroorzaken.

Functies

  • Inspecteer certificaatonderwerp en uitgever (voor wie het is, wie het heeft uitgegeven).
  • Valideer datums: notBefore / notAfter, en waarschuw bij dreigende verloopdatum.
  • Controleer SAN's (Subject Alternative Names) en hostname-dekking (www vs apex, subdomeinen).
  • Detecteer certificaatketenproblemen (ontbrekende tussenliggende certificaten / onvolledige keten).
  • Optioneel omleidingen volgen om de HTTPS-afdwinging van de laatste URL te valideren.
  • Identificeer veelvoorkomende HTTPS-valkuilen (verkeerde host, verkeerd certificaat, gemengde omleidingen).
  • Kopieervriendelijke resultaten en bevindingen voor incidenttickets.
  • Download JSON- en PDF-rapporten voor documentatie en regressiecontroles.

🧭 Hoe te gebruiken for tls-certificate-checker

1

Plak de URL om te testen

Voer de doel-URL in. Je kunt https://example.com plakken of zelfs http://example.com als je wilt bevestigen dat het uiteindelijk naar HTTPS upgradet.

2

Schakel "Volg Omleidingen" in voor realistisch gedrag

Als je de daadwerkelijke bestemming wilt valideren die gebruikers en crawlers bereiken (http→https, non-www→www), houd dan Volg Omleidingen ingeschakeld.

3

Voer de controle uit en bekijk de samenvatting

Controleer de belangrijkste punten: geldigheidsdatums, hostname/SAN-overeenkomst en of de keten compleet is.

4

Inspecteer bevindingen en los de oorzaak op

Als je waarschuwingen ziet (binnenkort verlopen, mismatch, onvolledige keten), los deze dan op in de TLS-terminatielaag (CDN, reverse proxy, load balancer of webserver).

5

Exporteer JSON/PDF voor tracking

Download een rapport om bij ops/SEO-tickets te voegen of om een voor/na-momentopname te bewaren.

Technische specificaties

Invoer en werking

Deze tool controleert een URL en inspecteert het TLS-certificaat voor het opgeloste HTTPS-eindpunt.

MogelijkheidDetails
Ondersteunde URL-vormenHTTP- of HTTPS-URL's (doorsturen kan worden ingeschakeld).
Afhandeling van doorsturenOptioneel; indien ingeschakeld, volgt het tot het geconfigureerde maximum aantal doorsturingen.
TLS-focusInspecteert certificaateigenschappen en veelvoorkomende misconfiguraties.

Standaardinstellingen en limieten

Ophaal- en veiligheidsstandaarden zijn afgestemd op voorspelbaar gedrag.

InstellingWaarde
Doorsturen VolgenIngeschakeld
Max. Doorsturingen10
Time-out15000 ms
User-AgentEncode64Bot/1.0 (+https://encode64.com)
PrivénetwerkenNiet toegestaan

Wat wordt gecontroleerd

Controles zijn ontworpen rond de meest voorkomende problemen in productie: vervaldatum, hostnaam-mismatch (SAN-dekking) en ketencompleetheid. Het volgen van doorsturingen helpt gevallen te identificeren waar HTTPS alleen geldig is op de uiteindelijke canonieke host.

Een geldig certificaat is noodzakelijk maar niet voldoende voor sterke beveiliging. Combineer dit met HSTS- en beveiligingsheader-audits voor verharde implementaties.

Opdrachtregel

Gebruik OpenSSL en curl om certificaatdetails vanuit je eigen terminal te bevestigen en te vergelijken met wat de tool rapporteert.

macOS / Linux

Toon certificaatketen (SNI) voor een host

echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null

Handig om het gepresenteerde bladcertificaat en de tussenliggende keten te inspecteren.

Extraheer vervaldatum snel

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Print notBefore / notAfter.

Lijst SANs

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Toont welke hostnamen het certificaat dekt.

Verifieer HTTP-doorsturing naar HTTPS

curl -I http://example.com

Controleer Location-header en uiteindelijk schema.

Volg doorsturingen en toon uiteindelijke URL

curl -IL http://example.com | sed -n '1,120p'

Helpt bij het detecteren van redirectketens en niet-canonieke eindpunten.

Gebruik altijd -servername met openssl s_client op virtueel gehoste servers/CDN's. Zonder SNI kun je het verkeerde certificaat krijgen.

Gebruiksscenario's

Voorkom uitval door verlopen certificaten

Identificeer certificaten die bijna verlopen, zodat je kunt vernieuwen voordat gebruikers en bots browserfouten tegenkomen.

  • Wekelijkse certificaatgezondheidscontroles
  • Audit domeinen na DNS- of CDN-wijzigingen

Los problemen met onvolledige certificaatketens op

Detecteer ontbrekende tussenliggende certificaten (gebruikelijk bij aangepaste serverconfiguraties) die oudere clients en sommige crawlers verstoren.

  • Verkeerd geconfigureerde Nginx/Apache ketenbundel
  • Load balancer mist tussenliggende certificaten

Debug hostname/SAN-mismatch (www vs apex)

Bevestig dat het certificaat de exacte host dekt die gebruikers bereiken, inclusief www/non-www en subdomeinen.

  • Apex werkt maar www niet
  • API-subdomein ontbreekt in SAN-lijst

Controleer HTTPS-afdwinging via redirects

Zorg ervoor dat http-URL's doorverwijzen naar het canonieke https-eindpunt met een geldig certificaat.

  • http→https met 301
  • non-www→www canonicalisatie

❓ Frequently Asked Questions

Waarom kan een browser 'certificaat niet vertrouwd' zeggen, zelfs als HTTPS is ingeschakeld?

Veelvoorkomende oorzaken zijn een verlopen certificaat, een onvolledige keten (ontbrekend tussenliggend certificaat), een hostname-mismatch (SAN bevat de host niet), of het serveren van het verkeerde certificaat door SNI/virtual hosting-misconfiguratie.

Wat zijn SAN's en waarom zijn ze belangrijk?

SAN's (Subject Alternative Names) zijn de hostnamen waarvoor een certificaat geldig is. Als je site toegankelijk is via zowel example.com als www.example.com, moet het certificaat beide dekken (of je moet consistent doorverwijzen naar een gedekte host).

Is het OK als http naar https doorverwijst?

Ja—dat wordt aanbevolen. Zorg er wel voor dat de uiteindelijke HTTPS-bestemming een geldig certificaat presenteert en dat de redirectketen kort en consistent is (geef de voorkeur aan 301 voor canonieke redirects).

Controleert deze tool TLS-versies/ciphers?

Deze tool richt zich op certificaatinspectie en veelvoorkomende misconfiguraties. Voor protocol/cipher-versterking (TLS 1.2/1.3, zwakke ciphers) gebruik je een speciale TLS-configuratiescanner.

Wat is het verschil tussen leaf-, intermediate- en rootcertificaten?

Het leaf-certificaat is het certificaat van je site. Intermediate-certificaten verbinden het met een vertrouwde root-CA. Browsers vertrouwen roots, dus ontbrekende intermediates kunnen voorkomen dat een geldige vertrouwensketen wordt opgebouwd.

Pro Tips

Best Practice

Vernieuw certificaten vroegtijdig en automatiseer vernieuwingen (ACME) waar mogelijk.

Best Practice

Zorg ervoor dat SAN's elke publieke hostnaam dekken die je gebruikt (www, apex, API-subdomeinen) of handhaaf één canonieke host via redirects.

Best Practice

Lever altijd de volledige keten (leaf + intermediates). Veel storingen ontstaan door onvolledige ketenbundels na migraties.

Best Practice

Als je redirects inschakelt, houd ze minimaal: één hop naar de canonieke https-URL is ideaal.

Best Practice

Combineer geldig TLS met HSTS en beveiligingsheaders voor sterkere real-world bescherming.

Additional Resources

Other Tools