(DC) What to include in a request
Explanation
A Certificate Signing Request (CSR) is a block of encoded text that contains server identification information used when generating an SSL Certificate. It is generated on the server or within an application where the certificate will be installed later and contains information that will be included in the certificate such as the organization name, and common name (domain name or FQDN).
Requesting a SSL Certificates requires that you complete a process on your server or within your application to generate a Certificate Signing Request (CSR). This process includes the generation of a private key that is used to "sign" a request that is authenticated when the certificate is received to ensure that the certificate matches. This creates the private-public key (private key / certificate) pair .
The process is unique to the web server software, host operating system or the application and are usually well documented and can be found within the web server, operating system or application documentation or via articles found on the internet via search. A collection of steps and procedures have been collected and can be found by clicking the blue "How do I generate a CSR?" button. We welcome instructions for applications, operating systems, and platforms that we have missed, just let us know.
 There are many different ways to create a certificate signing request (CSR). Click the button to learn more. |
|---|
A certificate authority will use a CSR to create the SSL certificate, but it does not need the private key. The private key must be kept secret. Never disclose your private key during the certificate generation process. The certificate created with a CSR will only work with the private key that was generated with it. So if it is lost, the certificate will no longer work, as the cryptographic process requires both the private and public key (included in the certificate) to work.
What to include in the request?
The following information is usually placed in the certificate request, but if any of the following is missing, it must be obtained before moving forward.
Field Name | What information needs to be provided? | Required or |
|---|---|---|
Private Key | NEVER include the private key during the certificate generation process. | NEVER |
Group Email |
A certificate is usually associated with a specific group or service. A group email ensures we can identify who the certificate belongs and that expiration notices are properly communicated to the owners, a group email address is required. The group email address is also used to send a created or renewed certificate email. The group email address must be an AD based group email or a UTLISTs email address. Depending on the certificate process, this may be included in the CSR. | Required |
CSR Block of Text | The CSR provided must be 2048-bit, base-64 encoded PEM (Privacy Enhanced Mail) format. It is usually readable text that is pasted into the request or attached in the form of a text file in the following format that includes the " -----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwgYkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMR8w
....
Q0uA0aVog3f5iJxCa3Hp5gxbJQ6zV6kJ0TEsuaaOhEko9sdpCoPOnRBm2i/XRDX2D
6iNh8f8z0ShGsFqjDgFHyF3o+lUyj+UC6H1QW7bn
-----END CERTIFICATE REQUEST-----What is a CSR/Private Key's bit length?The bit-length of a CSR and private key pair is measurement of complexity and strength of a SSL certificate's ciphers. A key length of 2048 is the defacto-standard for most communications, but there is an effort to double that to 4096. Key sizes greater than 2048 might be incompatible with some servers, applications or cloud providers. If you have the capability and compatibility to use a higher bit-length — do so, however, for maximum compatibility - use the default size of 2048. | Required |
Subject Alternative Name(s) (SANs) | SANs are provided as additional FQDNs that should be included in a CSR, and are the additional domain names or FQDNs that the certificate will be valid for. SANs provide the ability for the certificate to validate different spellings and variations of a host name. SANs must be related to the same server or application. Depending on the certificate process, this may be included in the CSR. | OPTIONAL |
Valid Term Length | Currently the maximum time a certificate is valid is one year. You can specify 1 year (365 days) or 398 days. In the past, there were 2-year and 3-year options, but they are no longer available. Please see: (DC) Certificate Validation limited to 1-year after 9/1/2020. |
OPTIONAL |