1. General CSR Creation Guidelines. Before you can order an SSL certificate, it is recommended that you generate a Certificate Signing Request (CSR) from your server or device. A CSR is an encoded file that provides you with a standardized way to send DigiCert your public key as well as some information that identifies your company and domain name.
2. May 13, 2019 You should obtain these from a trusted source like the certificate store on your local computer, or directly from the CA (the link to the certificate bundle is the last link at the bottom of the page). Archived Certificate Chains. Intermediate certificate chains for InCommon certificates issued before or on October 5, 2014 are preserved here.
3. How to Generate a CSR for F5 BIG IP (version 9) The following instructions will guide you through the CSR generation process on F5 BIG-IP Loadbalancer (version 9). To learn more about CSRs and the importance of your private key, reference our Overview of Certificate Signing Request article.

1. Generate Ssl Key From Certificate And In Common Law
2. Generate Ssl Key From Certificate And In Common Language
3. Generate Ssl Key From Certificate And In Common Math
4. Generate Ssl Key From Certificate And In Common Life

Jun 09, 2019  This article describes how to recover a private key after you use the Certificates Microsoft Management Console (MMC) snap-in to delete the original certificate in Internet Information Services (IIS). You delete the original certificate from the personal folder in the local computer's certificate store. Jan 25, 2011 The Information Security and Policy Office (ISPO) are pleased to announce the availability of a new enterprise certificate service offering with the InCommon Certificate Service to provide unlimited free SSL certificates campus. This new certificate service will replace the existing service we currently manage through Thawte. Certificate Signing Request (CSR) file: Used to order your SSL certificate and later to encrypt messages that only its corresponding private key can decrypt. When prompted for the Common Name (domain name), type the fully qualified domain (FQDN) for the site that you are going to secure.

Create a CSR using OpenSSL & install your SSL certificate on your Apache server

Use the instructions on this page to use OpenSSL to create your certificate signing request (CSR) and then to install your SSL certificate on your Apache server.

Restart Note: After you've installed your SSL/TLS certificate and configured the server to use it, you must restart your Apache instance.

For Ubuntu instructions, see Ubuntu Server with Apache2: Create CSR & Install SSL Certificate (OpenSSL). For other OS/platform instructions, see Create a CSR (Certificate Signing Request).

You can use these instructions to create OpenSSL CSRs and install all types of DigiCert SSL certificates on your Apache server: Standard SSL, EV SSL, Multi-Domain SSL, EV Multi-Domain SSL, and Wildcard SSL.

1. To create your certificate signing request (CSR), see Apache: Creating Your CSR with OpenSSL.

   Para un tutorial en español visite la página Apache Crear CSR.

2. To install your SSL certificate, see Apache: Installing & Configuring Your SSL Certificate.

   Visite nuestras instrucciones en español para Apache Instalar Certificado SSL.

I. Apache: Creating Your CSR with OpenSSL

Use the instructions in this section to create your own shell commands to generate your Apache CSR with OpenSSL.

Recommended: Save yourself some time. Use the DigiCert OpenSSL CSR Wizard to generate an OpenSSL command to create your Apache CSR. Just fill out the form, click Generate, and then paste your customized OpenSSL command into your terminal.

How to Generate a CSR for Apache Using OpenSSL

If you prefer to build your own shell commands to generate your Apache CSR, follow the instructions below.

1. Log in to your server via your terminal client (ssh).

2. Run Command

   At the prompt, type the following command:

   Note: Make sure to replace server with the name of your server.

3. Generate Files

   1. You've now started the process for generating the following two files:

      • Private-Key File: Used to generate the CSR and later to secure and verify connections using the certificate.
      • Certificate Signing Request (CSR) file: Used to order your SSL certificate and later to encrypt messages that only its corresponding private key can decrypt.

   2. When prompted for the Common Name (domain name), type the fully qualified domain (FQDN) for the site that you are going to secure.

      Note: If you're generating an Apache CSR for a Wildcard certificate, make sure your common name starts with an asterisk (e.g., *.example.com).

   3. When prompted, type your organizational information, beginning with your geographic information.

      Note: You may have already set up default information.

   4. Now, your OpenSSL .csr file is created.

4. Order Your SSL/TLS Certificate

   1. Open the .csr file you created with a text editor.

   2. Copy the text, including the -----BEGIN NEW CERTIFICATE REQUEST----- and -----END NEW CERTIFICATE REQUEST----- tags, and paste it in to the DigiCert order form.

5. Save Private Key

   Save (back up) the generated .key file. You need it later to install your SSL certificate.

6. Install Certificate

   After you've received your SSL certificate from DigiCert, you can install it on your server.

II. Apache: Installing & Configuring Your SSL Certificate

If you still need to create a certificate signing request (CSR) and order your certificate, see Apache: Creating Your CSR with OpenSSL.

After we've validated and issued your SSL certificate, you can install it on your Apache server (where the CSR was generated) and configure the server to use the certificate.

How to Install and Configure Your SSL Certificate on Your Apache Server

1. Copy the certificate files to your server.

   1. Log in to your DigiCert account and download the intermediate (DigiCertCA.crt) and your primary certificate (your_domain_name.crt) files.

   2. Copy these files, along with the .key file you generated when creating the CSR, to the directory on the server where you keep your certificate and key files.

      Note: Make them readable by root only to increase security.

2. Find the Apache configuration file (httpd.conf) you need to edit.

   The location and name of the configuration file can vary from server to server—especially if you're using a special interface to manage your server configuration.

   • Apache's main configuration file is typically named httpd.conf or apache2.conf. Possible locations for this file include /etc/httpd/ or /etc/apache2/. For a comprehensive listing of default installation layouts for Apache HTTPD on various operating systems and distributions, see Httpd Wiki - DistrosDefaultLayout.

   • Often, the SSL certificate configuration is located in a <VirtualHost> block in a different configuration file. The configuration files may be under a directory like /etc/httpd/vhosts.d/, /etc/httpd/sites/, or in a file called httpd-ssl.conf.

   One way to locate the SSL Configuration on Linux distributions is to search using grep, as shown in the example below.

   Run the following command:

   Note: Make sure to replace /etc/httpd/ with the base directory for your Apache installation.

3. Identify the SSL <VirtualHost> block you need to configure.

   If your site needs to be accessible through both secure (https) and non-secure (http) connections, you need a virtual host for each type of connection. Make a copy of the existing non-secure virtual host and configure it for SSL as described in step 4.

   If your site only needs to be accessed securely, configure the existing virtual host for SSL as described in step 4.

4. Configure the <VirtualHost> block for the SSL-enabled site

   1. Below is a very simple example of a virtual host configured for SSL. The parts listed in blue are the parts you must add for SSL configuration.

   2. Make sure to adjust the file names to match your certificate files.

      • SSLCertificateFile is your DigiCert certificate file (e.g., your_domain_name.crt).

      • SSLCertificateKeyFile is the .key file generated when you created the CSR (e.g., your_private.key).

      • SSLCertificateChainFile is the DigiCert intermediate certificate file (e.g., DigiCertCA.crt)

        Note: If the SSLCertificateChainFile directive does not work, try using the SSLCACertificateFile directive instead.

5. Test your Apache configuration file before restarting.

   As a best practice, check your Apache configuration file for any errors before restarting Apache.

   Caution: Apache won't start again if your configuration files have syntax errors.

   Run the following command to test your configuration file (on some systems, it's apache2ctl):

6. Restart Apache.

   You can use apachectl commands to stop and start Apache with SSL support.

   Restart Notes:

   If Apache doesn't restart with SSL support, try using apachectl startssl instead of apachectl start. If SSL support only loads with apachectl startssl, we recommend you adjust the apache startup configuration to include SSL support in the regular apachectl start command. Otherwise, your server may require to manually restart Apache using apachectl startssl in the event of a server reboot. This usually involves removing the <IfDefine SSL> and </IfDefine> tags that enclose your SSL configuration.

7. Congratulations! You've successfully installed your SSL certificate.

Testing Your SSL/TLS Certificate Installation

1. Browser Test

   1. For best results, make sure to close your web browser first and then re-launch it.

   2. Visit your site with the secure https URL (i.e., go to https://www.example.com not http://www.example.com).

   3. Be sure to test your site with more than just Internet Explorer. IE downloads missing intermediate certificates; whereas, other browsers give an error if all the certificates in the certificate chain aren't installed properly.

2. DigiCert^® SSL Installation Diagnostic Tool

   If your site's publicly accessible, use our Server Certificate Tester to test your SSL/TLS certificate installation; it detects common installation problems.

Troubleshooting

1. If your web site's publicly accessible, our SSL Certificate Tester tool can help you diagnose common problems.

2. If you receive a 'not trusted' warning, view the certificate details to see if it's the certificate you expect. Check the Subject, Issuer, and Valid To fields.

   1. If it's the certificate you expect and the SSL certificate is issued by DigiCert, then your SSLCertificateChainFile is not configured correctly.

   2. If you don't see the certificate you expect, then you may have another SSL <VirtualHost> block before the one you recently configured.

      Name based virtual hosts aren't possible with https unless you use the same certificate for all virtual hosts (e.g., a Wildcard or a Multi-Domain SSL certificate).

      This is not an Apache limitation, but an SSL protocol limitation. Apache must send a certificate during the SSL handshake before it receives the HTTP request that contains the Host header. Therefore, Apache always sends the SSLCertificateFile from the first <VirtualHost> block that matches the IP and port of the request.

3. For help moving your certificates to additional servers or across server platforms, see our OpenSSL export instructions.

4. If you need to disable SSL version 2 compatibility in order to meet PCI Compliance requirements, add the following directive to your Apache configuration file:

   If the directive already exists, you may need to modify it to disable SSL version 2.

5. For instructions on how to fix common errors and for additional tips, see Troubleshooting Apache SSL Certificate Errors.

Apache Server Configuration

Generate Ssl Key From Certificate And In Common Law

For information about Apache server configurations that can strengthen your SSL environment, see the following resources:

• /mh-generations-key-quests-village.html. For Instructions on disabling the SSL v3 protocol, see Apache: Disabling the SSL v3 Protocol.

• For information about enabling perfect forward secrecy, see Enabling Perfect Forward Secrecy.

Terms of Service

Your use of InCommon/Sectigo certificates shall be governed by the terms of InCommon's Relying Party Agreement.

Server certificate articles in the Sectigo KB

General FAQ

Generate Ssl Key From Certificate And In Common Language

1. Where can I learn more about this program?

   See the InCommon Certificate Service page. Note also the Support page.

2. When is this program ready for campus?

   We can issue certificates now.

3. What is the procedure for a campus unit to acquire SSL certs?

   Send your request along with a CSR (created using a 2048-bit or larger public key), and specifying the server software type (e.g. Apache/ModSSL,Tomcat, Microsoft IIS 5.x+ or, if unknown or generic, OTHER), to calnet-admin@berkeley.edu and CalNetOps staff will handle the request and issue the certificates. The CSR file text content should be pasted into the message or appended as a *.txt file (not a *.csr file to avoid being stripped by ServiceNow). We have implemented the InCommon-Sectigo CA Service's ability to delegate some PKI administration to departmental authorities. See the DCA FAQ section of this page. This distributed administrative model has been discussed and implemented in coordination with the campus CalNetIdM and steering committees, and with the campus general security committee, CISPC.

4. Why does my server's Security Contact need to be involved?

   Before we have fully implemented distributed administration, we are using the Security Contact application to help to validate requests for server certificates. In light of this, you might want to forewarn the folks on your Security Contact mailing list about any pending certificate request for an IP address for which they have security notification responsibility.

5. Does this system have the capability to do Subject Alternative Name (SAN) certificates where we can use one certificate with multiple DNS hostnames per IP address?

   Yes, the following types of certificates are supported to use the SAN field: InCommon Multi Domain SSL (SHA-2), InCommon Unified Communications Certificate (SHA-2), Sectigo EV Multi Domain SSL (SHA-2).

6. What are the available lifetimes for certificates?

   We can issue 1- or 2-year certificates. We will provision a 2-year certificate unless requested otherwise.

7. How does Sectigo handle certificate revocation lists (CRLs)?

   See this Sectigo KB article and also note that each certificate provisioned will have a X509v3 CRL Distribution Points entry for live access to the current CRL.

8. What is the major difference between UCC/SAN and Multi-Domain/SAN certificates (MDC)?

   The main (and perhaps only) difference is that the MDC can have theSubject CN (or primary domain name) set to a group name:essentially a non-valid domain name. All of the requested FQDNs willappear as dnsName entries in the SubjectAltName (SAN) extension.The UCC certificate is identical in that the requested FQDNs are inthe SAN field, but it also contains a valid FQDN as the CN in the Subject. Other than this, these two types of certificates appear to be functionally equivalent.

9. How do I generate a CSR and install the signed certificate?

   For help with generating a CSR and other certificate issues, consult the Sectigo Knowledge Base for your web-server type. Note that for UCC/SAN or Multi-Domain/SAN certificates the CSR you generate only needs to be for the single Common Name domain, aka the Primary Domain Name. Additional domains that you may require in the Subject Alternative Name will be added at the time of provisioning the certificate, but in any case should always be listed in your Service Request or to your Departmental Certificate Administrator. Note also that you must create at least 2048-bit key pairs as in the examples listed below.

10. What information needs to be included in the CSR for a SAN certificate?
    Optionally in the CSR itself, but required in the requesting e-mail, please list the primary Subject CN (fully-qualified DNS name, FQDN) required, and any additional CNs (as FQDNs) to be added to the SAN field of the provisioned certificate. For example, the request might be:

    Please provision a Multi-Domain/SAN certificate as follows: myhost.berkeley.edu (primary), myhost-b1.berkeley.edu, myhost-b2.berkeley.edu using the included CSR.
    To create a certificate containing both a wildcard name and a non-wildcard name, enter the non-wildcard name as the CN and the wildcard name as one in the SAN field, and request an InCommon Multi Domain SSL certificate type.
    

11. How can I validate that my certificate is correctly installed on my server?
    In addition to using validation web sites such as the Sectigo SSL Checker, you can use the OpenSSL tool, s_client as follows, for example:

    openssl s_client -host somehost.berkeley.edu -port 443 -showcerts -verify 3
    

12. How can I create a CSR with a SAN field?
    Note that having the SAN field defined in the CSR is nota requirement, but this can be submitted if desired. For example, with the Java 7 keytool you can use the following syntax with the BASH shell on RHEL:

    export JAVA_HOME=/opt/jdk1.7.0
sudo ${JAVA_HOME}/bin/keytool -genkeypair -alias tomcat
-keyalg RSA -keysize 2048
-dname 'CN=myhost.berkeley.edu,
OU=MyDept,
O=University of California at Berkeley,
L=Berkeley,
S=California, C=US'
-ext 'SAN=DNS:myhost.berkeley.edu,DNS:myhost-b1.berkeley.edu,DNS:myhost-b2.berkeley.edu'
-keystore /etc/tomcat6/tomcat6_keystore.jks
sudo ${JAVA_HOME}/bin/keytool -certreq -alias tomcat
-file /etc/tomcat6/certs/myhost.csr -sigalg SHA256withRSA
-ext 'SAN=DNS:myhost.berkeley.edu,DNS:myhost-b1.berkeley.edu,DNS:myhost-b2.berkeley.edu'
-keystore /etc/tomcat6/tomcat6_keystore.jks

13. What about doing that using OpenSSL?
    Sure, thanks to Jim Blair, see this Python example code.

14. I'm new to dealing with X.509 certificates, CSRs and all of this. Would you walk me through the basic steps necessary to generate a keypair and CSR using the gencert script and install, let's say, an InCommon SSL certificate for an Apache HTTP Server (httpd) on RHEL 6 using this service?
    Sure, see this Extended example page for a step-by-step description of the process for generating and installing an InCommon SSL certificate.

15. How about some help with IIS servers and X.509 certificates?

    Sectigo does provide some KB articles dealing with several versions of IIS for CSR generation and installation of the certificates. See, for example, CSR Generation, and SSL Installation Instructions. See also this solution (#2) for a problem with importing certs for use with IIS 7.

16. What about other DNS domains such as anyplace.org? Can you issue certificates for such domains?

    The CalNet InCommon-Sectigo CA is currently registered to issue certificates for the berkeley.edu domain and its DNS subdomains plus a few other domains that InCommon has approved following our request for authorization to issue certificates on behalf of the domain. We can request to add any other DNS domains which we control or own, and for which we can provide to InCommon: (1) evidence of ownership and (2) proof of control of the DNS domain in question. For DNS domains that we do not own, this CalNet InCommon-Sectigo CA will not apply so standard certificate requesting procedures with an external CA will be necessary.

17. What is the cost to the campus unit, if any?

    There is no direct cost to campus units as UC Berkeley has paid the InCommon-Sectigo CA institutional fee.

18. My client certificate was issued as a PKCS#12 (.p12) certificate. How do I convert it to a PEM certificate?
    You can convert the certificate using openssl as long as you have the PIN created when you downloaded the client certificate:
    

Departmental Certificate Administrator (DCA) FAQ

Generate Ssl Key From Certificate And In Common Math

1. What is a DCA?

   This is the local UC Berkeley campus name for what is referred to as a DRAO (Department Registration Authority Officer) in the InCommon documentation.

2. What is expected of a DCA?

   • The primary responsibility that a DCA has when issuing or renewing a certificate is to verify that requests for certificates are legitimate. If the DCA does not personally know the person making the certificate request and their business need for the certificate, due diligence would be expected in tracking down a responsible person within the DCA's unit who can vouch for the legitimacy of the the request.
   • Keeping a record of requests and their confirmations, e.g. an e-mail log for each request, for at least three years to allow for auditing of past transactions would also be expected of the DCA.
   • Another requirement is to learn to use the InCommon CSM administrative tool for managing certificates as documented in the InCommon CA CSM RAO Admin Guide.
     

3. What are some policies and best practices for a DCA?

   • Do not issue wildcard certs without asking for a review by the CalNetIdM team.

     Note that the Information Security Office (ISO) has designated the use of a wildcard cert for the root domain (*.berkeley.edu) as requiring UC P4 data classification of the host.

     We will consult with Security Operations to make sure that there is a good reason for using a wildcard cert vs. using a SAN certificate. For customers with a handful of certs, Multi-Domain/SAN certs might be the best approach. For services with multiple services on many clustered hosts, wildcard certs might work best, though there is more risk that way if the private key is compromised.

     Our expectation is that any wildcard cert be issued with a new private key for each renewal time and with a term of no longer than 1 year.
   • Document all steps performed for the validation of requests for certs such as checking with hostmaster on hostname ownership, checking with DNS data, etc. We will try to come up with standard procedures based on the experiences of the initial DCAs.
     

4. Some tips for generating CSRs

   • For hosts that may have domain components that start with a number, for example, host.1918.berkeley.edu, the Java keytool may complain when generating keypairs. Use instead OpenSSL-based techniques.
   • Multi-Domain/SAN certs: use the gencert script (modified for your environment) to simplify the use of OpenSSL.
     

5. How many DCAs should a department have?
   This will vary depending on the volume of requests for certificates or renewals. If a unit has a request volume that would impact business needs were the primary DCA not available to fulfil these requests, having a designated backup DCA would be appropriate.

6. How can I sign up to become a DCA?

   If you are interested in performing the DCA function for your unit, please forward your request along with the contact information for a person responsible for your department's or unit's business functions, for example, a departmental manager or MSO or chairperson, to calnet-admin@berkeley.edu for consideration and also to schedule a training session.

7. How are DNS domains assigned to a DCA?

   When you apply for becoming a DCA, please also list the DNS domains and hostnames for which you would like to be responsible for issuing certificates. It is possible to request additional domains via the InCommon Admin tools, but the initial setup will be smoother if we can provision most of these up front. Examples of UC Berkeley DNS domains and hostnames you might request are: *.mysubdom.berkeley.edu, myhost1.berkeley.edu, *.mysubdom.1918.berkeley.edu, myshost2.1918.berkeley.edu, etc. The wildcard names represent subdomains which you can claim as being responsible for the identity of all of the hosts.

8. How do I use the InCommon Certificate Manager to request a new hostname or domain for my department?

   Starting at the Settings tab, select the Departments menu item. Now click the Domains button in the Controls column for your department. Finally, click the Add button to request a new hostname or domain to be added to the list for your department (the name appears in red text while pending approval). This request will generate an e-mail notice to the appropriate administrator for approval. When the approval step has been completed you will be able to provision certificates for the newly delegated domain.

9. What to put in the External requester field?

   This depends on whether you want the person listed receiving the notices generated at the various stages of certificate provisioning.

10. What is Certificate Discovery?

    This feature allows you to set up a scan of a subset of the network to create an inventory of certificates and their expiration dates. Be sure to create a Discovery Scan Summary notification before running the scan to ensure that the report is delivered correctly.

11. What is the IP address used for the Certificate Discovery feature?

    The discovery scans come from one IP address (91.199.212.132), which is secure.comodo.net.

12. Is there an API that I might use to automate some tasks?

    In API Documentation, Sectigo has documented the REST APIs for the Certificate Manager (CSM) which underlies the InCommon Certificate Service Manager (CSM) web application used by the InCommon Certificate Service.

13. We need to submit an emergency certificate request this weekend. What is the turnaround from Sectigo on weekends?

    It can take up to 24 hours. If you need expedited issuance of a certificate, please file a ticket with Sectigo mentioning the order number.

14. What effect does the Server Software option (which shows in the Request New SSL Certificate form) have on the issued certificate?

    One known effect is to escape certain special characters. For example, in the address fields, the string #1500 becomes #1500 when selectingMicrosoft IIS 5.x and later as the Server Software type.

15. How can a renew a cert for a new term and update it to use an SHA-2 signature and, optionally, replace the key (via the CSR) at the same time?
    Try this procedure in the InCommonCM app:

1. In the list of certificates, select a certificate to update and hit the Renew button. Answer OK to the prompt presented.
2. Select the newly created entry (which has the Requested status) and click the Edit button.
3. Change the Type to one of those with (SHA-2) in the profile name.
4. Change other details such as the Term and CSR, if desired.
5. Click OK and approve the edited request.
16. How can I create a wildcard certificate containing non-wildcard names?
    To create a certificate containing both a wildcard name and a non-wildcard name, use the InCommon Multi Domain SSL certificate type and enter the non-wildcard name as the CN and the wildcard name as one in the SAN field.

Tips for other campuses

Generate Ssl Key From Certificate And In Common Life

If you are contemplating the InCommon Certificate service at your campus, feel free to borrow advice from UC Berkeley on Implementing the InCommon Certificate Service.