Why does Semrush say I have an incorrect certificate?

Semrush Site Audit gives websites an error issue for incorrect certificate if the SSL or TLS certificate is improperly configured. There are many reasons why a certificate could be incorrectly set up - as there are many different types of SSL certificates for different reasons.  

Possible Reasons Why the Error is Reported

One common incorrect use of a certificate is failing to cover all areas of your hostname.

It is possible for a lower level certificate like a Domain Validation Certificate to cover your root domain (semrush.com) but fail to cover all of your subdomains (www.semrush.com, example.semrush.com, etc).

Since there are types of SSL certificates that can cover multiple domains, you can also run into the issue of having subdomains from one site covered but failing to cover all subdomains of another site.

See in the image below how the subdomains where the certificate is issues don’t match the domain used for the Semrush Project.

In this case, you would need to acquire the proper certificate for your situation. If you need to secure all of the subdomains under a single domain, the best fit would be a wildcard certificate. These certificates are indicated by an asterisk (*.semrush.com) to indicate it covers all subdomains (blog.semrush.com, www.semrush.com, news.semrush.com, etc).

If you can’t get a wildcard certificate, another option would be to list every subdomain as alternative names in your certificate.

Types of SSL Certificates

In order to know which certificate is appropriate for you, make sure you know about the many different types of SSL certificates. There are SSL certificates that you can acquire within minutes to secure a single site, and SSL certificates that can secure up to 250 domains with a single certificate.

Types Based on Validation Level

• Domain Validation Certificates (least strict, any domain can get one)
• Organization Validation Certificates (middle tier)
• Extended Validation Certificates (most strict, intended for professional businesses)

Types Based on Number of Domains to Secure

• Single-name SSL certificates (covering a single domain/subdomain)
• Wildcard SSL certificates (covering all subdomains on a domain)
• Multi-domain SSL certificates (covering multiple domains)

Checking Your SSL Certificate

To check your SSL certificate, you can use the SSL Server Test from Qualys. This will show you all of the certificate settings and issues with the certificate.

When an SSL or TLS certificate is incorrectly implemented, your site is not fully protected from attackers or hacking attempts. This puts the security of everyone’s information that goes on your website at risk.

By fixing such issues, your visitors will be protected from attacks and all of the information that goes through your website will be safe. Especially for sites that deal with financial or personal information, a correct certificate is essential.

How can it be fixed?

Contact your webmaster or hosting company (wherever the certificate was issued from) and ask them to install the correct certificate that covers all areas of your hostname.

Hostname Coverage

Github gives the following advice on their website about hostname coverage:

Ensure that your certificates cover all the names you wish to use with a site. Your goal is to avoid invalid certificate warnings, which confuse users and weaken their confidence.

Even when you expect to use only one domain name, remember that you cannot control how your users arrive at the site or how others link to it. In most cases, you should ensure that the certificate works with and without the www prefix (e.g., that it works for both example.com and www.example.com). The rule of thumb is that a secure web server should have a certificate that is valid for every DNS name configured to point to it.

Wildcard certificates have their uses, but avoid using them if it means exposing the underlying keys to a much larger group of people, and especially if doing so crosses team or department boundaries. In other words, the fewer people there are with access to the private keys, the better. Also be aware that certificate sharing creates a bond that can be abused to transfer vulnerabilities from one web site or server to all other sites and servers that use the same certificate (even when the underlying private keys are different).
For more information, read Github’s Best Practices for SSL and TLS.