Topics Map > Campus Services > SSL Certificate
SSL Wildcard Certificates
This document provides important information regarding what a wildcard certificate is as well as advantages and disadvantages to using this type of certificate.
- When generating a CSR for a Wildcard Certificate you will need to set the common name to department.wisc.edu and request *.department.wisc.edu as the additional domain (SAN) so that both department.wisc.edu and *.department.wisc.edu are valid. If you generate the certificate with only *.department.wisc.edu the base domain of department.wisc.edu will not be valid.
- You will also need to submit as a Multi-Domain request in the form at https://servercertificates.wisc.edu, where you can specify *.department.wisc.edu as the additional domain.
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.
- Note: 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 re-issuance 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.
Wildcard Certificates Terms of Service
- Wildcard certificates will not be issued for second level domains we administer e.g. wisc.edu, wisconsin.edu, etc.
- Wildcard certificates are not preferred for systems that store or access restricted data.
- After expiration, wildcard certificate renewal requests must be created with a new key pair.
- Requestor/Owner of wildcard certificates asserts that suitable administrative, technical and a physical safeguard are in place to protect the private key and also agrees to:
- 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.