SSL/TLS uses x509 certificates to secure digital communications. These certificates are bound to a particular DNS name, and signed by a Certificate Authority. Browsers attempt to validate the certificate by chaining back to a root certificate in its root certificate store. If a website does not have an SSL/TLS certificate installed that matches the DNS name by which it was accessed, it is an indication that a Man-In-The-Middle attack might be occurring. What if, administratively, you want a single certificate (and its corresponding private key) to be valid for multiple DNS names? In this case, there are two options: SAN Certificates and Wildcards. SAN Certificates (named for the DNS extension attribute Subject Alternate Name) allows an administrator to request that a certificate be valid for a list of DNS names provided when creating the Certificate Signing Request (CSR). Wildcard Certificates on the other hand, make use of the regular expression * in the subject alternate name such that any DNS name under that umbrella, either now or in the future, is covered by the certificate. It is important to note that a wildcard certificate is valid only for one level. There is no such thing as a wildcard certificate valid for two levels below a domain name. That is, *.domain.com will NOT cover the hypothetical my.blog.domain.com. (For this we would need another wildcard certificate for *.blog.domain.com).
For example, the following entries in the CSR determine the kind of certificate:
Regular Certificate: www.domain.com will appear in the Common Name attribute and in the SAN attribute.
SAN Certificate: www.domain.com will appear in the Common Name attribute, but both www.domain.com AND domain.com will appear in the SAN attribute.
Wildcard Certificate: *.domain.com will appear in both the Common Name and the SAN attribute.
Isn’t that a security risk?
Everything we do as security professionals balances risk and reward. There is nothing inherently insecure about a SAN certificate or a Wildcard Certificate, but it does make it easier to ignore best practice. If an organization has a single wildcard certificate that it installs on every endpoint, they’re putting all of their eggs in one basket. Should an attacker compromise any of those servers and obtain the private key, all the organization’s communications can be decrypted with impunity. There are however, a lot of compelling reasons for using a Wildcard Certificate.
When to use a Wildcard Certificate
One such use case is for a company that provides a multi-tenanted application. This is a very popular strategy for Software-As-A-Service (SAAS) companies. Different companies that subscribe to the service will each have their own subdomain of the SAAS provider, all pointing to a singular application that apartments access based on the SNI name coming in. The company may not know all the domain names that will need to be covered by the Wildcard Certificate before installing it on their server. Another time when a Wildcard Certificate makes a lot of sense is if an organization makes their internal services available behind a load balancer. Many organizations will install the certificate at the load balancer, and reverse proxy requests to the backing application. Often the requests will be re-encrypted by the load balancer, but the load balancer will be configured to use an internal Certificate Authority. Other organizations will simply terminate the request and pass the traffic over HTTP to the backing application. (This is a considered poor practice today).
Wildcard Certificates are also a great was for companies to save on costs. Instead of buying multiple certificates for all your sub-domains, a single certificate can cover them all for under $100.
When to use a SAN Certificate
SAN certificates are useful when different domains need to be trusted by the same certificate. Remember, a wildcard is only able to provide access to any DNS name in a single level of a single subdomain. Another common strategy for SAAS companies to provide their service “white labeled”. In this configuration, the organization purchasing the service wants it to appear as if it’s under their own portfolio of services. They will point a DNS name to the service provider, and the service provider will include the SAN name for multiple clients in the certificate. For each domain, the CA will need to validate the issuance with the owner on record of the subdomain, so this strategy can get complicated quickly. Another good use of a SAN certificate is for clustered servers. Many times an administrator will want to make each cluster member addressable by either its node name or by the cluster name. SAN certificates are perfect for this use.
Mitigating Risk
Since SAN Certificates and Wildcard Certificates make key theft more attractive to an attacker, there are some strategies that should be employed to securely manage private keys. On Windows Systems, you can bind a private key such that it can only be accessed via an AD User or Security Group. On Linux, file system permissions are commonly used to keep private keys secure. One step further than this would be investing in a hardware security module (HSM) that only keeps private keys in hardware and allows applications to interact with them via special APIs.
Discussions and Comments
Click here to view and join in on any discussions and comments on this article.
