Skip to end of metadata
Go to start of metadata

Notice - The UWCA is scheduled for retirement TBD

On TBD, the UWCA will no longer issue new certificates.

All clients and servers relying on UWCA certificates should plan to migrate to InCommon certificates as soon as possible. This change will not impact InCommon certificates. 

UW-IT will briefly continue to maintain both the UWCA and InCommon Certificate Services to allow sufficient time for customers to transition. Please transition to an InCommon certificate as soon as possible. 

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.

If you a a client of a service relying on UWCA certificates you must continue using UWCA certificates until your service provider begins accepting InCommon certificates. 


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. 

InCommon certificates have a lifespan of one year intervals, as browsers require shorter lifespans for increased security. 

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 to let us know.
  • If you want us to use a different contact for future communications about UWCA Retirement, please email

  • 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

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

MilestoneStatusDate completedNotes
Process for Linux server based service providers defined(tick) Completed2021-05-01

Process for Windows server based service providers defined

(tick) Completed2021-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

  • No labels

1 Comment

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


    Is the application certificate for the MCP crypto API certificate used for SSL with the NXEdit application.


    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 ( doesn't work and return all RDNs. The first in the list is country RDN 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.