Checking your website's HTTPS health takes a few minutes and catches problems such as expiring certificates and missing security headers before visitors notice.
Most website owners only think about their SSL certificate when a browser shows a big warning and visitors start emailing. A short routine check can catch problems before that happens and spot other easy security improvements at the same time. This guide walks through three checks you can run in a few minutes with free tools on DomainBullet: the SSL certificate, HTTP response headers and open ports.
None of this replaces a professional security review, but it covers common, visible issues that are easy to fix.
Certificate lifetimes and your HTTPS health
Certificates expire more often than many site owners expect. Apple's support documentation states that TLS server certificates issued on or after September 1, 2020 must not be valid for more than 398 days. Email delivery depends on TLS too: Google's sender guidelines require a TLS connection for transmitting email. Check certificate expiry dates regularly, and automate renewals wherever possible.
Check 1: Your SSL/TLS certificate
Your certificate is what lets browsers connect to your site over HTTPS and confirms they're talking to the real site. Enter your domain in the SSL Checker to see:
- Who issued the certificate
- When it's valid from and until
- Which protocol and cipher are in use
- An overall grade
What to look for
Expiry date. Expired certificates cause browser warnings that scare visitors away. Many hosts and services renew certificates automatically, but automation fails sometimes, for example after a DNS change or if a validation file is blocked. Note the expiry date and check again a couple of weeks before it.
Name coverage. The certificate must cover every name visitors use, such as both example.com and www.example.com. If one of them isn't covered, visitors using it will see a warning.
Protocol versions. Modern sites should use TLS 1.2 or TLS 1.3. Older protocols have known weaknesses. If your report shows old protocols enabled, ask your host to disable them.
Grade. A low grade usually points to old protocols, weak ciphers or configuration problems. The report details help you or your host find the cause.
If your certificate is about to expire
- Check whether your host or CDN renews it automatically.
- If you use CAA records, make sure they allow the certificate authority you use. You can see CAA records in the DomainBulleter.
- Confirm your DNS still points to the server that handles renewal.
Check 2: HTTP security headers
When your server responds to a request, it sends headers along with the page. Some of these headers tell browsers to enable extra protections. Enter a URL in the HTTP Headers Checker to see all response headers, grouped into security, caching and general, with a score for security headers.
The headers that matter most
Strict-Transport-Security (HSTS). Tells browsers to always use HTTPS for your site, even if someone types http://. Once your HTTPS setup is solid, this is a valuable addition. Start with a short duration and increase it once you're confident.
Content-Security-Policy (CSP). Restricts which sources the page may load scripts, styles and other resources from. It's powerful protection against some injection attacks, but it needs careful setup, because a too-strict policy can break your site. Many sites start with a report-only policy.
X-Content-Type-Options: nosniff. Stops browsers from guessing file types, which closes off a class of attacks. Simple to add.
X-Frame-Options or CSP frame-ancestors. Controls whether other sites can embed your pages in frames, which protects against clickjacking.
Referrer-Policy. Controls how much of your URL is shared with other sites when visitors click a link. strict-origin-when-cross-origin is a sensible default.
Permissions-Policy. Lets you switch off browser features your site doesn't use, such as the camera or microphone.
Information leakage
Look at headers like Server and X-Powered-By. They sometimes reveal exact software versions. That isn't a vulnerability by itself, but there's rarely a reason to advertise it. The Server OS Checker shows what can be inferred about your stack from headers alone, which is a good reminder of how much they reveal.
How to add headers
Headers are set in your web server configuration, your hosting control panel, a CDN, or a plugin for platforms like WordPress. After adding them, re-run the checker to confirm they're present.
Check 3: Open ports
Every service running on a server listens on a port. Websites use ports 80 (HTTP) and 443 (HTTPS). Other common ports include those for email, databases, file transfer and remote administration.
The Port Checker tests a set of common ports on a host and shows which are open. Only test servers you own or have permission to test.
What to look for
- Web ports (80 and 443) are expected to be open on a web server.
- Database ports (for example 3306 for MySQL or 5432 for PostgreSQL) generally shouldn't be reachable from the internet. Databases should usually only accept connections from your own servers.
- Remote access ports (like 22 for SSH or 3389 for Remote Desktop) are often necessary, but they're frequent targets. Restrict access by IP address where possible, use keys or strong authentication, and keep the software updated.
- Old or unused services, such as plain FTP, should be turned off if you don't need them.
If something is open that shouldn't be, ask your host or administrator to close it with a firewall rule.
Bonus: check who hosts the site
If you manage several sites, or you've inherited one, Who Is Hosting shows the hosting provider, IP, network and related services, which helps you figure out where to make changes.
A monthly ten-minute routine
- Run the SSL Checker and note the expiry date.
- Run the HTTP Headers Checker and compare the security score with last month.
- Run the Port Checker against your own servers and confirm nothing unexpected is open.
- Check your domain's expiry in a WHOIS lookup, because an expired domain takes everything down with it.
Write down the results each month. Changes you didn't expect are often the first sign that something needs attention.
These checks won't make a site bulletproof, but they catch the most visible problems early. If you have questions about your results, contact us.
Key takeaways
- Confirm the certificate is valid, trusted and not near expiry
- Review security headers such as HSTS and Content-Security-Policy
- Close ports you don't need
- Know your host for when you need support
- Automate certificate renewal
Frequently asked questions
How often should I check my SSL certificate?
Monthly is a sensible habit, plus after any server or hosting change. Automated renewal reduces the risk further.
What security headers should my site have?
Common ones include Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and Referrer-Policy.
Why should I check open ports?
Unneeded open ports can expose services to the internet. Only the ports your site needs should be reachable.
How can I find out who hosts a website?
A hosting lookup tool checks the IP address and network owner behind a domain.
Is a free certificate as secure as a paid one?
For encryption, yes. Free and paid certificates use the same technology; paid ones may add validation or support.
