SSL Wildcard Certificates
SSL Wildcard Certificates
What is a wildcard certificate?
Certificate containing the wildcard character * in the CN of the subject (server) are considered wildcard certificates.
For example, instead of requesting four certificates for the web sites department.wisc.edu, mail.department.wisc.edu, login.department.wisc.edu, and anything.department.wisc.edu, a single certificate could be generated using the CN=*.department.wisc.edu. Any subdomain of the domain department.wisc.edu could use this wildcard certificate for SSL based communications.
The primary advantage to using a wildcard certificate is to reduce administrative time to request and manage multiple certificates and key pairs.
Prior to the flat-fee InCommon certificate service, there was also a financial advantage to using wildcards. For a large number of servers and websites, it cost less to buy a wildcard certificate than to buy individual certificates for servers or websites that shared a common domain.
The primary disadvantage to use of wildcard certificates is related to protection of the private key. With a wildcard certificate, the risk/possibility of key compromise is increased because:
Private key is likely shared among individuals.
Private key is likely shared among servers or devices.
Private key, by definition, is widely used.
It is difficult to keep something shared private.
The effect of a key compromise is magnified because it potentially affects a larger number of machines and services rather than a single certificate:
-a machine or private key compromise requires revocation and reissuance for many machines or services rather than a single machine or service.
- a private key compromise allows impersonation and man in the middle attacks. While this is true of traditional certificates, a larger number of services and machines could be attacked rather than a single machine or service.
Most devices properly handle wildcard certificates but not all i.e. this means there may be end user related issues in acceptance, etc.
From an operational perspective, when the wildcard certificate expires all services using the the certificate must be updated versus each individual certificate with expiration dates throughout the year.
Balancing the tradeoffs discussed above, the following terms of service will be used for wildcard certificate approval and issuance:
1. Wildcard certificates will not be issued for second level domains we administer e.g. wisc.edu, wisconsin.edu, etc.
2. Wildcard certificates should not be used for systems that store or access restricted data.
3. Wildcard certificates will be limited to a validity period of 2 years.
4. After expiration, wildcard certificate renewal requests must be created with a new key pair.
5. Where possible, wildcard certificates should not be used in cases where there are less than 10 fully qualified domain names needed. Multi-domain SSL certificates should be considered in these cases.
6. Requestor/Owner of wildcard certificate asserts that suitable administrative, technical and a physical safeguard are in place to protect the private key and also agrees:
- To track the following information about the wildcard certificate/keys:
- Servers (and location) where the private key is stored
- other locations, where private key is stored e.g. backups
- people and applications with access to the private key
- To revoke and reissue the wildcard certificate with new key material if a known compromise occurs of a server containing the private key of the wildcard certificate.
8. The Chief Information Security Manager (CISM) must approve exceptions to these guidelines.
9. Delegated departmental/division SSL administrators agree to follow the same guidelines for issuing wildcard certificates.