Web Certificates

Terms of Service

• SSL Certificates

• CSR Generation

• SSL Installation Instructions

General FAQ

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) using the Service Request Form via ServiceNow.  CalNetOps staff will handle the request and issue the certificates. 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 developer and steering committees, and with the campus general security committee, CISPC.

4. 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), and InCommon Unified Communications Certificate (SHA-2).

5. What are the available lifetimes for certificates?

   We can issue 1-year certificates.

6. 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.

7. 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 the Subject CN (or primary domain name) set to a group name: essentially a non-valid domain name. All of the requested FQDNs will appear as dnsName entries in the SubjectAltName (SAN) extension. The UCC certificate is identical in that the requested FQDNs are in the 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.

8. 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.

9. 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. 
   
   

10. 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
    
    

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

    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/tomcat9/tomcat9_keystore.p12
    
    sudo ${JAVA_HOME}/bin/keytool -certreq -alias tomcat \
      -file /etc/tomcat9/certs/myhost.csr -sigalg SHA256withRSA \
      -ext "SAN=DNS:myhost.berkeley.edu,DNS:myhost-b1.berkeley.edu,DNS:myhost-b2.berkeley.edu" \
      -keystore /etc/tomcat9/tomcat9_keystore.p12

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

13. 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 8 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.

14. 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.

15. 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.

16. 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.

17. 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:
    

    # 1. Convert certificate .p12 file into .pem file.  When prompted enter the PIN you created when downloading the certificate.
    
    openssl pkcs12 -clcerts -nokeys -out username_cert.pem -in username.p12
    
    # 2. Convert key .p12 file into .pem file. When prompted for the import password enter the PIN you created when downloading the certificate.  When prompted for the PEM pass phrase enter a password of your choice.
    
    openssl pkcs12 -nocerts -out username_key.pem -in username.p12
    
    # 3. Remove encryption from key .pem file.  When prompted enter the pass phrase from the previous step.
    
    openssl rsa -in username_key.pem -out username_key_noenc.pem
    
    # 4. Merge the certificate from step 1 and unencrypted private key from step 3 into a single PEM.
    
    cat username_cert.pem username_key_noenc.pem | tee username.pem
    
    # 5. Be sure to store your certificates in a secure location.
    
    

Departmental Certificate Administrator (DCA) FAQ

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 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 OpenSSL-based techniques instead.
   • 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 fulfill 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. How can I 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.
15. 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.