The intermediate certificate that InCommon uses to sign TLS/SSL certificates will be expiring in 2024.
Starting August 31, 2023, all TLS/SSL certificates issued or renewed through the InCommon Certificate Service will be signed by a new intermediate certificate that is valid until 2032. People who use TLS/SSL certificates to secure their websites, servers, or devices will need to take action in order to continue to use TLS/SSL certificates. This change does not affect certificates issued by Let’s Encrypt.
Everyone can start requesting certificates signed by the new intermediate certificate right away. There is no need to wait for them to become mandatory on August 31.
WASUP users
Every certificate you own on each system that uses a certificate will need to be addressed. You can do this as each of your certificates expires starting from August 31, 2023 until October 5, 2024, or you can choose to switch to using the new intermediate certificate early for some or all of your certificates.
To request a certificate that uses the new intermediate certificate before August 31, 2023, put “V2 cert, please!” in the Comments field in WASUP when you submit the request for a new or renewed certificate.
If you install leaf certificates separately from intermediate/root certificates, then download and install the new intermediate certificate on each of your systems that use certificates before installing a certificate that uses the new intermediate certificate on that system. Depending on the software that uses the certificate, you may need to create a symbolic link named using the new intermediate certificate’s hash value in the same directory in order to enable your software to find the new intermediate certificate.
If you install leaf certificates together with the intermediate certificate(s) (and possibly the root certificate) in a single file, make sure you include the new intermediate certificate with it.
Starting August 31, 2023, all new and renewed certificates you receive will use the new intermediate certificate and you will need to either make sure that the system you install them on has the new intermediate certificate on it, or you will need to include the new intermediate certificate in the same file as the new or renewed certificate.
If you are currently using WASUP, you may want to start switching to ACME now in order to automate certificate renewals. Google has announced their intention to reduce the maximum certificate lifetime that Google Chrome will accept from the current 398 days to only 90 days at some point in the future. After that point, people who continue to use WASUP will need to use it to renew each certificate—and install the renewed certificates on their systems—four to five times per year. ITS does not know when the current 398 day certificates will no longer be available and all new certificates will be valid for only 90 days, but we believe that it has a good chance of happening near the end of 2024. By starting your switch to ACME now, you can identify websites and systems that may have difficulty with ACME and have time to plan and implement solutions.
ACME users
ITS recommends obtaining a new “Universal ACME” enrollment account to replace each enrollment account you currently have, and then configuring all your systems to use the new account(s). The Universal ACME enrollment accounts have new features and multiple certificate profiles that are not available through the old ACME enrollment account. If you are an InCommon Certificate Manager user, you may be able to create the new enrollment account(s) yourself. Otherwise, submit a request to obtain a new enrollment account(s).
ITS believes that old ACME enrollment accounts will switch to using the new intermediate certificate on August 31, 2023. However, we cannot guarantee this. Switching to new enrollment accounts before August 31, 2023 can provide certainty and avoid any disruption around the time of the switchover date. If the old ACME enrollment accounts do not switch automatically, you may need to gradually replace old enrollment accounts (before ACME-issued certificates start expiring) with new enrollment accounts after August 31, 2023.
For each new enrollment account, you will receive a new ACME server URL, EAB KeyID, and EAB HMAC Key. On each system that obtains certificates using the corresponding old enrollment account, configure your ACME client software to use the new values rather than the old values. If you are using Certbot, you can change all three values in the file /etc/letsencrypt/cli.ini
Make a backup of the certificates and private keys your system uses, then test the new enrollment account by forcing the renewal of one of the certificates that your system obtained via ACME. If you are using Certbot, you can force a dry-run renewal of a certificate using the command certbot -v renew --force-renewal --dry-run --cert-name CERTNAME where CERTNAME is the name of the certificate as shown by the command certbot -v certificates If this succeeds, you may want to run it again without the --dry-run option in order to actually renew the certificate.
The following table is for ACME users who manage their ACME accounts themselves using the InCommon Certificate Manager web application.
| OLD InCommon Intermediate Certificate (expiring in 2024) |
NEW InCommon Intermediate Certificate (expiring in 2032) |
|
|---|---|---|
| ACME server URL | https://acme.sectigo.com/v2/InCommonRSAOV | https://acme.enterprise.sectigo.com |
| Enrollment account type | https://acme.sectigo.com/v2/InCommonRSAOV | Universal ACME |
| Profile names | n/a | V2 InCommon Multi Domain SSL |
InCommon Certificate Manager users
If you have “Allow SSL Auto Approve” turned on for your InCommon Certificate Manager user account, you will not be able to use the Renew button in the InCommon Certificate Manager web application for a certificate that was issued against the old intermediate certificate. If this affects you, use the “+” button to add a new certificate and select the Certificate Profile “V2 InCommon Multi Domain SSL” (or “V2 InCommon Wildcard SSL Certificate” if you are obtaining a wildcard certificate). You can then download the newly issued certificate either by itself, with the new intermediate certificate, or as a full certificate chain.
If you haven’t already, you may want to start implementing ACME on your systems now in order to automate certificate renewals. Google has announced their intention to reduce the maximum certificate lifetime that Google Chrome will accept from the current 398 days to only 90 days at some point in the future. After that point, people who continue to issue and renew certificates by hand in the InCommon Certificate Manager will need to use it to renew each certificate—and install the renewed certificates on their systems—four to five times per year. ITS does not know when the current 398 day certificates will no longer be available and all new certificates will be valid for only 90 days, but we believe that it has a good chance of happening near the end of 2024. By starting your switch to ACME now, you can identify websites and systems that may have difficulty with ACME and have time to plan and implement solutions.
Frequently asked questions
I don’t understand what an intermediate certificate is or why it affects the certificates I use on my systems. Can someone explain all of this?
Sure! Please read What Is an SSL Certificate Chain & How Does It Work?
If you have any questions, contact us at [email protected] or post in the Michigan IT Slack channel #incommon-certificate-service (you will need to join the Michigan IT Slack workspace first, if you are not already a member)
Almost all commercial TLS/SSL certificates are signed by intermediate certificates rather than root certificates. Intermediate certificates are typically valid for 10 years. InCommon has been issuing certificates signed by an intermediate certificate that was created in 2014 and expires in 2024. In late 2022, InCommon created a new intermediate certificate that they have been using since March 2023 to sign some certificates. The new intermediate certificate will be used to sign all certificates starting on August 31, 2023, and it will remain valid until 2032.
Do all my systems need to be configured for the new intermediate certificate by August 31, 2023? Is this a deadline?
No. August 31, 2023 is just the date when no more certificates signed by the old intermediate certificate can be issued.
Systems will keep working until they need a new certificate. You will usually want to replace a certificate a reasonable amount of time before it expires (30 days in advance is best). At that point, the system will need to be configured with the new intermediate certificate (if you are using WASUP or ICM) or they might need switched to a new ACME enrollment account (if you are using ACME and the old enrollment account does not switch over to the new intermediate certificate automatically).
What happens if I don’t do anything?
If you use ACME and the old enrollment account does not switch to the new intermediate certificate automatically, then your certificates will fail to renew starting August 31, 2023, potentially causing outages or other service disruptions as each certificate reaches its expiration date over the course of the next 12 months. If this happens, you should have approximately 30 days notice before any certificates expire.
If you use WASUP or the InCommon Certificate Manager, and you install leaf certificates separately from intermediate/root certificates, then new certificates you receive starting August 31, 2023, will not work until you download and install the new intermediate certificate.
All existing certificates will remain usable for their full lifetime, even if that is after August 31, 2023. No certificate will become invalid early.
Can I get more time or an exception?
No, this change and the date are being enforced by the vendors (InCommon and Sectigo) in order to ensure that the longest certificate that can be issued on August 30, 2023 (which can be valid for 398 days) will expire before the old intermediate certification becomes invalid on October 5, 2024. The university had no input on these dates and neither the university nor the vendors are able to change them.
How can I tell if I need to take action? Or how can I tell if a certificate uses the old or the new InCommon intermediate certificate?
Inspect each certificate your systems use to identify themselves to clients and other systems. If the common name (CN) of the issuer starts with "InCommon" and ends in “CA” (for example, “InCommon RSA Server CA”), the certificate uses the expiring intermediate certificate and you need to take action. If the common name (CN) of the issuer starts with "InCommon" and ends with “CA 2” (for example, “InCommon RSA Server CA 2”) then you are already using the new intermediate certificate and you do not need to do anything else.
- You can inspect the certificate remotely using your web browser or the following command (change the website name in both places)
openssl s_client -connect example.umich.edu:443 -servername example.umich.edu < /dev/null 2>&1 | grep "issuer=" - You can inspect a PEM-encoded certificate file using the command
openssl x509 -in name-of-certficate-file.cert -noout -issuer
If the common name (CN) of the certificate issuer does not start with "InCommon" and end with either "CA" or "CA 2" then the certificate is not a TLS/SSL certificate ("server certificate") issued through the InCommon Certificate Service and it is not affected by the change in InCommon intermediate certificates.
Resources
- What Is an SSL Certificate Chain & How Does It Work?
- InCommon Certificate Service at the University of Michigan