Risk of using a same wildcard certificate on Internal and External URL’s

We at DarkNext Cybersecurity would often come across clients that would ask us “Is it safe to use a wildcard SSL certificate?” or “is it safe to use the same wildcard certificate on Internal and as well as Publically exposed websites?”

Practically, most of the companies would use a wildcard SSL certificate primarily because of two reasons:

  1. It is easier to maintain a wildcard certificate
    efficiently.
  2. Reduced cost for the organization.

Keeping in mind that both of the reasons are absolutely valid and important, we wanted to highlight the risk of using wildcard certificates. In most cases, all websites under the wildcard certificate will share the same private key. In case, one sub-domain or server is compromised and private key is stolen it may be possible to decrypt traffic on other sub-domains using the same certificate.

What is a wildcard certificate?

A single wildcard certificate for https://*.example.com will secure all these subdomains on the https://*.example.com domain:

  • mail.example.com
  • contact.example.com
  • login.example.com
  • www.example.com

Instead of getting separate certificates for subdomains, you can use a single certificate for all main domains and subdomains and reduce costs.

For e.g., Google may use the same wildcard certificate for mail.google.com, images.google.com, maps.google.com, etc.

In our scenario, we have our own subdomain called hackme.darknext.com that has been issued a wildcard certificate *.darknext.com. We have deployed a wildcard SSL certificate by letsencrypt.

This is what the SSL certificate looks like:

As shown above, we have 3 files a certificate, ca_bundle and a private.key. We would be using Wireshark for the decryption of our key. In order for decryption to work, We need to ensure that the private key is RSA key. This can be verified by opening our key with notepad.

Another thing to remember is that decryption will not happen if the key exchange algorithm is Diffie Hellman (DHE). This can be verified by SSLScan

In our case, Diffie Hellman was used so we had to disable the ciphers temporarily in firefox.

As shown below, our browser shows that the connection is secure.

We will now import the stolen private key into Wireshark as shown below.

We are now all set to see the decryption happen. We go to our test website and enter “pwned by DarkNext!” as a username and password.

As shown below, Wireshark was successfully able to decrypt the SSL traffic.