Digital Certificate FAQ

TLS Certificate Frequently Asked Questions

How do I generate a Certificate Signing Request (CSR)?

Consult the documentation for your particular web server, as each one is slightly different. 
Sectigo offers instructions for various packages at to help you.

InCommon -

My server has an "alias" and a "real" name... which one do I use for the server name (Common Name) in the CSR?

Generate the certificate request using the name that visitors will type, (and the name that links referring to your site use), to prevent client browser warning messages.

What domains are eligible to use this service?

The University of Iowa owns the University's Top Level Domain (TLD) or root domain "", which is registered with our InCommon account. 
All systems within this Top Level Domain (TLD) are eligible to request certificates through this service.

Can I request a digital certificate for a host?

Yes — as long as the University owns the domain.
To ensure the university's compliance with the InCommon agreement, requests for certificates outside of UI's .edu domains are subject to extra vetting and approval, by both the university and possibly InCommon. To begin your request, send an email to with a request for the new domain. The ISPO will initiate the validation process with InCommon. Once validated, requestors can then request a certificate for a host in that domain through the normal channels.

Wildcard certificate use on campus.

Do not issue wild-card certs without asking for a review by the Information Security and Policy Office (ISPO). We will consult with the requestor to make sure that there is a good reason for doing this. Now that we can generate certs on demand, and use SAN certs, there may be less need to use wildcard certs. But with UCC/SAN certs you would have to reissue every time you add a new host. For customers with a handful of certs, UCC/SAN might be best approach. For services with multiple services on many clustered hosts, wildcard might work best, though there is more risk that way if the private key is compromised.

What if I make a mistake on the certificate request?

Please read and follow the instructions carefully, you can revoke the TLS certificate using your pass-key phrase.

When I go to my website, I see an error message.

Troubleshooting this, and "other" TLScertificate errors visit: Sectigo's TLS Certificate Troubleshooter for more information.

What is the best way to test a server configured with a TLS certificate issued by the InCommon Certificate Service?

Exercise caution when using a browser to test your server configuration. Some browsers (such as Firefox) will store intermediate CA certificates received from a server in the browser's certificate store, so unless you're careful, you may be tricked into believing your server is configured correctly when in fact it's not. To avoid this pitfall, use openssl to definitively test your server configuration:

openssl s_client -connect server:port -CApath /etc/ssl/certs/

If the client machine does not have an /etc/ssl/certs/ directory, download the AddTrust External CA Root certificate, and try the following command instead:

openssl s_client -connect server:port -CAfile AddTrustExternalCARoot.crt

In either case, if certificate validation succeeds, you know your server is configured correctly. Let's try a specific example:

$ openssl s_client -connect -CAfile AddTrustExternalCARoot.crt
Certificate chain
0 s:/C=US/postalCode=48104/ST=MI/L=Ann Arbor/street=1000 Oakbrook Drive, suite 300/O=InCommon CA/OU=PlatinumSSL/
i:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA
1 s:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

In the example above, note that there are three certificates in the certificate chain. This means that both the intermediate CA certificate (InCommon Server CA) and the root CA certificate (AddTrust External CA Root) are configured on the server. Only the intermediate CA certificate is required, however. The root certificate does not have to be configured on the server.

Validation Levels

OV: Organization Validated certificates include full business and company validation from a certificate authority using currently established and accepted manual vetting processes.
EV: Extended Validation certificates provide the highest levels of encryption, security and trust and immediately reassure web site visitors that it is safe to conduct online transactions by turning the address bar green on next generation browsers.

Certificate Types

SDC: Single Domain Certificates will secure a single fully qualified domain name.
WC: Wildcard Certificates will secure the domain and unlimited sub-domains of that domain.
MDC: Multi-Domain Certificates will secure up to 100 different domain names on a single certificate.

TLS Certificate Best Practices | Requesting TLS Certificates |