Wildcard x509 SSL/TLS Certificates
Class: Service Design, Service Implementation
Background
| Type of Certificate | URL Example |
|---|---|
| Single-domain | https://www.unm.edu |
| Multi-domain (UCC) | https://www.unm.edu https://www.unm-prod.edu https://www.unm-intg.edu |
| Wildcard (*) | https://www.unm.edu https://www.unm.edu https://web.unm.edu https://news.unm.edu https://search.unm.edu |
A "wildcard certificate" is a certificate which contains, as possible server name, a "*" character. Details are in RFC 2818, section 3.1. Essentially, when the server certificate contains *.example.com, it will be accepted by clients as a valid certificate for any server whose apparent name matches that name.
In general practice, the Information Security & Privacy Office does not recommend the use of wildcard certificates. If wildcard certificates are to be used, they should be used sparingly.
Wildcard certificates shall be implemented in a manner that compartmentalizes the risk of that wildcard being compromised. For instance, authentication services shall not use a wildcard certificate; in the event that that wildcard were to be compromised on another service or server, that authentication service’s private key would also be compromised.
Risks
- Wildcard certificates decrease the effectiveness of fraud-containment measures
- Spreading the same private key across multiple servers, each providing different services, allows an exploited security issue in any one of those services to leverage the private key against everything that key is intended to protect
Potential Benefits
When it’s not okay to use wildcards
- Across many services of differing purposes
- On site / applications that collect, store, transmit or process Personally Identifiable Information (PII) or Sensitive and Protected Information (SPI) except those behind load balancers, Next Generation Firewalls (if doing x.509 de/encrypt inspection), Application Firewalls (F5), or other devices which multiple servers and / or services reside behind
When it’s okay to use wildcards
- On servers / applications that together offer a service or redundancy of a service
- In a complex isolated application with many components
- A server with multiple applications (the ISPO does not recommend hosting many applications on a single server)
- On load balancers, Next Generation Firewalls (if doing x.509 de/encrypt inspection), Application Firewalls (F5), or other devices which multiple servers and / or services reside behind
The ISPO utilizes the University’s enterprise ticketing system Help.UNM and intake services provided by the UNM Information Technologies (UNM IT) Service Desk, the University's central support organization for information technology-related services and computer-related issues. All information security-related events, incidents, and requests are forwarded to the ISPO by UNM IT Service Desk Staff. If you have feedback or questions regarding this document, please use Help.UNM or call the UNM IT Service Desk at 7-5757 to ensure that your request is opened, tracked, and processed in a timely manner.
