What should I put in the ‘Domain’ field of my CSR (Certificate Signing Request)?

Every Certificate Signing Request (or CSR) needs to include the name of what you intend to protect.

Related Content

Want to keep learning?

Subscribe to SSL.com’s newsletter, stay informed and secure.

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 secure.mydomain.com, 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.

Wildcards

For a wildcard certificate, enter the domain name, proceeded by an asterisk and a period – for example:

*.mydomain.com

A wildcard certificate covers all the subdomains of a given domain – the example above would secure both secure.mydomain.com and shop.mydomain.com.

UCC/SAN Certificates

Multiple domains (up to 500!) 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.

Thank you for choosing SSL.com! If you have any questions, please contact us by email at Support@SSL.com, call 1-877-SSL-SECURE, or just click the chat link at the bottom right of this page.

Stay Informed and Secure

SSL.com is a global leader in cybersecurity, PKI and digital certificates. Sign up to receive the latest industry news, tips, and product announcements from SSL.com.

We’d love your feedback

Take our survey and let us know your thoughts on your recent purchase.