Skip to main content

System Status: 

Wildcard Certificates

This page explains why Wildcard SSL certificates are not supported on and may not be used for UCSD systems and suggests a number of alternatives.

Did you know? SSL certificates are provided to UCSD faculty and staff at no-charge. We can usually fulfill a certificate request within 24 hours.

See the full SSL request documentation.

What is a Wildcard Certificate?

SSL certificates are often seen as that piece of digital magic that ensures all the traffic between a website and a user is encrypted. However this is only part of what a certificate does. Certificates are a means to reasonably validate that the system which a client is connecting to is in all likelihood the system which the client was expecting to communicate with, i.e. confirm that a Man in The Middle attack hasn’t taken place. To do this, the client (the user’s browser) will validate the server certificate presented by the server by ensuring that:

  • The certificate has been issued (and thus signed) by a Certificate Authority (CA) which the client trusts. This is why SSL certificates for the UCSD domain may only be issued by the campus certificate service and not any other third party.
  • The certificate has been issued for the domain on which the server is running on. (bob.ucsd.edu can’t be running on bob.ucsd.edu.flybynight.com; we regularly see these sorts of scams.)
  • The certificate has not expired.
  • The certificate has not been revoked.

A wildcard certificate is one that doesn’t verify a single domain (bob.ucsd.edu) but rather an arbitrary number of subdomains (*.bob.ucsd.edu). Thus the same wildcard certificate can be used for a.bob.ucsd.edu, b.bob.ucsd.edu, etc. This certificate can therefore be used across multiple (even hundreds or thousands) of servers. If any of those servers are compromised it can mean that the certificate can be used maliciously as part of a MiTM attack. (Read more about MiTM attacks. Note: commercial site.)

If compromised by attackers, wildcard certificates have the potential to be far more damaging to UCSD than standard SSL certificates, since they could be used to spoof any host in the domain of the wildcard. When bad actors infiltrate your domain, they can gain privileges that allow them to create unlimited domains—all encrypted by your wildcard certificate. Worse still, these subdomains will appear to be valid. These illegitimate subdomains allow bad actors to host malicious websites that they can use in phishing campaigns.

Another common use case for wildcard certificates are services, such as blogs, that host multiple instances of a service each at a custom subdomain (e.g., wordpress.com may offer bob.wordpress.com, ted.wordpress.com, or alice.wordpress.com for customers Bob, Ted, and Alice). While wildcard certificates may ease administrative tasks, you are compromising security by significantly increasing risk for that convenience. A stolen certificate can wreak havoc.

Alternatives to Wildcard Certificates

The standard SSL certificate includes a protocol for associating a single certificate with multiple domains, the Alternate Subject Name field. When a certificate is created you can enter up to 100 alternative domain names that will be recognized as valid during the certificate validation process (and up to 256 by special handling). In practice this addresses almost all of the situations where one might use a wildcard certificate. For dynamic websites that rely on subdomains, we recommend deploying the service to use a directory form, (e.g., wordpress.com/bob, wordpress.com/ted, wordpress.com/alice) and to create redirects on the web server for the vanity URLs. For example, bob.wordpress.com resolves to wordpress.com/bob. This permits the marketing of the custom domain while using a single domain certificate on the application server. Note that this does mean that a compromised subdirectory site may require replacing the root certificate for the entire domain.

Emergency and Unusual Situations

There are a handful of situations where the risks associated with a wildcard certificate are warranted, generally these are for load balancers, HPC clusters or similar SSL chokepoints that may be protecting hundreds or thousands of hosts. We’ve also granted short-term exemptions for units that may have once received a wildcard certificate and have failed to plan to transition away from them.

If you are in one of these situations please contact the certificate service manager via email at pki-certs@ucsd.edu and explain your situation. Note that these are rarely approved and require unit/college leadership acceptance of the risk.

References

Much of this article shamelessly borrows from Sean Write's blog.