Every Certificate Signing Request (or CSR) needs to include the name of what you intend to protect. Typically this is a domain name of the site you are aiming to protect.
Protecting What You Aim to Protect
Different environments use different tools to create a CSR, and may ask for this domain name when using different terms – in Apache, it’s called the Common Name, while cPanel just asks for Domains. (Java-based servers ask for a first and last name, but really need a domain name. Go figure.)
Whatever the term, this field technically requires the fully qualified domain name (or FQDN) for the site you wish to cover. Although strict rules are applied to FQDNs (including a period on the end of the name) you can generally use the “common name” – so if the website you want to protect is
just enter that name.
Note that many SSL.com certificates will by default cover a domain name and the www. subdomain – so ordering a Basic SSL certificate (for example) for
mydomain.com will also secure www.mydomain.com.
For a wildcard certificate, enter the domain name, proceeded by an asterisk and a period – for example:
A wildcard certificate covers all the subdomains of a given domain – the example above would secure both
Multiple domains (up to 2000!) can be covered in one type of certificate, variously called a Unified Communications Certificate (UCC) or Subject Alternate Name (SAN) certificate. Domain names submitted for a UCC are entered one per line, following the same rules as for other certificates. A UCC can also include wildcard domains.
What about IP addresses and internal addresses?
Local IP addresses and internal names (commonly used in internal networks) could be covered by digital certificates in the past.However, due to serious security issues, these are no longer offered, and existing certificates incorporating these are slated for retirement by November 1, 2016. For more information on how to secure internal names, see this article from our knowledge base.