As part of ongoing UW Information Technology (UW-IT) efforts to ensure we are running modern and supported infrastructure, we have begun the process of retiring the legacy UW Certificate Authority (UWCA).
The UWCA, an IAM maintained certificate authority, was created in 2005 for two purposes: to provide free certificates for web applications and free certificates for client-server authentication. It assures that owners of a certificate with a particular CN and alt-names actually have control of that CN and alt-names. UW’s DNS Contacts service provides this proof of control.
In 2005 a 1024 bit number was a big number, and the UWCA’s signing key length was established at 1024 bits. Today, 4096 bits is a big number and smaller numbers are no longer considered secure by many vendor applications and libraries, causing them to reject UWCA issued certificates. To this legitimate complaint the UWCA has no sustainable technological solution.
A thorough analysis of options clarified that transitioning from using UWCA issued certificates to InCommon certificates is the most sustainable remediation and leaves the least technical debt:
- From the UW-IT perspective, providing a single CA is a cost saving and simplifying option.
- Through our affiliation with InCommon, UW-IT already provides free certificates for all UW applications.
- Acquiring an InCommon certificate requires the same certification mechanisms used by the UWCA.
- InCommon certificates, issued by Sectigo, are accepted by all browsers, vendors, and modern libraries.
Application owners that rely on UWCA certs for client-server authentication are free to choose any option that suits their needs, but as far as a UW-IT supported option goes, we are recommending the use of InCommon certificates for this purpose.
Plan
For now, UW-IT will continue to maintain both the UWCA and InCommon Certificate Services in tandem to allow sufficient time for customers to transition. We will work with our customers to provide support and instructions about reconfiguring their services to trust InCommon certificates. We will begin limiting the creation of new UWCA certificates on TBD, blocking all creation of UWCA certificates on TBD and retiring the service when existing UWCA certificates have expired and there is no longer any dependence on the UWCA, date TBD.
Communications - notices and reminders
We will reach out to customers through channels like the TechSupport and Certificate Services mailing lists to inform application owners who currently use the UWCA about the timeline for retirement and encourage them to migrate to using InCommon certificates. We will also direct retirement notices and reminders to server owners individually (as best as we can identify them). Additionally, we will work with teams internal to UW-IT to retire use of UWCA certificates, including remaining uses on UW-IT Managed Servers, web services and REST API clients.
Client Recommendations - Requesting a InCommon certificates
As the UWCA is retiring, users of UWCA certificates should look to obtain a certificate via the InCommon CA. Users are able to have more than one certificate for the same domain, so they can create their InCommon certificate while still using the UWCA certificate until the service has transitioned. The process to do so can be found on the following page:
Obtain a Certificate from the InCommon CA
If the services being utilized is accepting InCommon certificates, users should switch to their InCommon certificate. Most authorizations are based on the certificate domain name instead of underwriting certificate authority, so previous authorizations are unlikely to need to be altered.
Service Provider Recommendations - for notices and migrations
Recommended actions for notices:
- If you're a service provider who plans to migrate from using UWCA certificates to InCommon certificates, please email iam-support@uw.edu to let us know.
If you want us to use a different contact for future communications about UWCA Retirement, please email iam-support@uw.edu.
If the DNS contact information for your server is incorrect and you want to correct it, please refer to the Network Portal to make changes to DNS contact information.
If you don’t understand why you received a notice or reminder, please email iam-support@uw.edu.
Recommended actions for migrations:
- For linux servers the Apache directive SSLCACertificateFile indicates which CAs are acceptable for client certificate authorization.
- If your application runs on a UW-IT provided linux system the transition is very easy:
- This directive presently allows only UWCA client certificates.
- SSLCACertificateFile /usr/local/ssl/certs/ca-uwca.pem
- This directive will allow UWCA and InCommon client certificates.
- SSLCACertificateFile /usr/local/ssl/certs/ca-incommon-uwca.pem
- This directive will allow only InCommon client certificates.
- SSLCACertificateFile /usr/local/ssl/certs/ca-incommon.pem
- If you operate your own installation the method is the same, although the paths will vary.
- For Windows servers, no changes are needed as InCommon certs are trusted unless an administrator has removed it from the default set of root CAs trusted.
Project Timelines
Milestone | Status | Date completed | Notes |
---|
Process for Linux server based service providers defined | Completed | 2021-05-01 |
|
Process for Windows server based service providers defined | Completed | 2021-06-16 |
|
UW-IT Internal systems supporting InCommon certificates |
|
|
|
Announcement to UW-IT customers to ensure support of InCommon certificates |
|
|
|
Retirement Announced on Tech Support and Certificate Services mailing list |
|
|
|
Limit issuance and retirement dates defined |
|
|
|
End Issuance |
|
|
|
Retire UWCA permanently |
|
|
|
1 Comment
Alan Lechtenberg
The MCP Engineering team would appreciate a Milestone for
Process for MCP server based service providers defined.
Right now we have a list of our services certificates here: Certificate Manifest
In our certificate requests the vendor differentiates the service the certificate is for, in the OU of the certificate. A "+" character is used as separators in the OU, which is allowed by the standards ( RFC2986 ).
For example
OU="MCAPI+S+NXEDIT+SSL"
Is the application certificate for the MCP crypto API certificate used for SSL with the NXEdit application.
Similarly
OU="MCAPI+S+SOCKETS+ALERTAPI"
Is the application certificate for the MCP crypto API certificate used for SSL with the ALERT API
InCommon throws an error (exception 14) for certificate requests that have a "+" character in the OU.
Sectigo recorded this as a defect, indirectly, in their software
SCM-4468 - Cannot request cert with the attached CSR getting error Exception -14 on seemingly valid Web API call
"Looks like a bug in bouncy castle library we use for dealing with CSR.
Somehow filter by CN OID (2.5.4.3) doesn't work and return all RDNs. The first in the list is country RDN 2.5.4.6. That is why SCM use it instead of CN."
In theory the fix was released by Sectigo in the release with SCM update 21.11 on Nov 21, 2021. I question that though, as the certificate that appears to have been generated by the testing for the telnet service on chasqui on 11/22/21, has on OU-"UW-IT". Which, of course, does not have the "+" characters
For more details see: REQ4948491
Right now the UW-IT Certificate Service will generate a OU of UW-IT for both of these certificates (OU="MCAPI+S+NXEDIT+SSL" and OU="MCAPI+S+SOCKETS+ALERTAPI") which means if we were to use InCommon certificates we could not tell the certificates apart.
As a result, we are still dependent upon UWCA certificates.
Jim Tomlinson has been very helpful working with us on this since August of 2021, but at this time, a year later, it is still not resolved.