The browser also allows you to view the certificate yourself, should you want more detailed information about the issuer, subject, or public key. You can view all the details of why the browser declares the certificate as secure.

It’s issued by a trusted Certificate Authority (CA), in this case a free CA called Let’s Encrypt

It hasn’t expired yet

It uses a strong encryption algorithm for the public key

This brings up a few common issues we see that make certificates insecure:

The certificate is expired. Many companies don’t have a master list of certificates and their expiration dates, which can lead to forgotten certificates that don’t get replaced until a penetration test or customer complaint highlights the issue.

The certificates is for the wrong website. Occasionally, companies many forward domain names to the server that uses the certificate or change existing ones without updating the certificate itself. Since the certificate wasn’t issued for the additional or modified domains, it is not a valid certificate for those domains.

The certificate is self-signed. While it’s generally okay to self-sign certificates for fully internal sites provided the signing authority has been added to the trusted certificate store for all devices on the network, all external-facing sites should use an SSL certificate signed by a trusted Certificate Authority (CA). The dangers with untrusted self-signed certificates are: An attacker could create their own self-signed certificate that looks nearly identical to the legitimate one. Many users will refuse to use the site because of the security errors browsers will show. Users who are willing to use the site will become accustomed to using sites with certificate errors, making them more likely to ignore these errors on a malicious site.



Encryption Ciphers and Protocols

Now that your webpages are being served over HTTPS with a valid certificate, let’s think about the strength of the encryption itself. Think of Julius Caesar using the now famous Caesar Cipher to encrypt secret military messages. Centuries later, it’s best not to use that cipher because it was cracked and is now common knowledge. If you’re interested in the history of encryption, Simon Singh’s The Code Book is a great read.

For the purposes of securing a website, we need to use complex encryption protocols and ciphers. Because attackers are always looking for flaws in these protections, we must always keep one step ahead and be sure to avoid using any weaker ciphers or protocols. SSLScan is a free tool that runs on Linux, Windows and macOS. Here is an SSLScan for https://raxis.com/. For a free online tool that can assess the ciphers and protocols on external facing sites, check out Qualys’ SSL Server Test. SSLScan shows all protocols and ciphers that the site accepts. Weak protocols and ciphers, if they were enabled for the site, would be listed in yellow or red.

Two types of protocols are commonly used: SSL (Secure Sockets Layer) and TLS (Transport Layer Security). All versions of SSL have been compromised and should not be used. There are multiple known exploits that attackers can use to gain access to your data or cause a denial of service attack if the data is transmitted using SSL. At the time of writing, the recommended protocol is TLSv1.2, although TLSv1.1 can be secure if configured correctly. TLSv1.3 is currently being drafted, so be sure to keep an eye out for that in the future. We always recommend removing weak protocols, such as SSLv2, SSLv3, and TLSv1.0, because SSL/TLS implementations support a downgrade process that allows an attacker to bypass a server’s secure protocols in favor of less secure protocols.