IT Connect

Information technology tools and resources at the UW

20151102: Certificate services for delegated OUs

The UW Windows Infrastructure has deployed a public key infrastructure consisting of a 2 tier certificate authority, whose initial purpose is to provide automatic certificate enrollment and certificate deployment for delegated OU computers running Windows.

 

What and When:

On 10/16/2015, UWWI deployed an Active Directory published root certificate authority named netid-root-CA. Being AD published means that domain-joined computers trust it by default.

 

On 10/23/2015, UWWI deployed an Active Directory integrated issuing certificate authority named netid-issuing-CA. Being AD integrated means that:

  • domain-joined computers trust it by default,
  • domain users and computers can request and retrieve certificates from it, leveraging the secure channel trust already in place
  • issued certificates can be published to the appropriate AD object (which enables a variety of uses)
  • certificate revocation lists are published to AD, enabling domain-joined computers to reliably determine whether a given certificate is still valid

 

Like the UW Services CA, these certificate authorities are not publicly trusted. This limits their usefulness to UW internal purposes—for example, you wouldn’t use this CA to enable HTTPS for a public website.

 

In the near future, on a per OU basis, we’ll provide a group which OU admins will be member managers for. You can add computers as members to this group to direct them to automatically enroll for a “Computer” certificate, with client authentication and server authentication uses. Unlike most other certs you’ve used, these certs automatically get renewed, and require no further human involvement. More details on the nature of these certs is available below. More details on this coming capability will be shared when this is ready.

 

What You Need to Do:

At this time nothing. We wanted to let security conscious customers know that we changed the certificate authority trust of domain-joined computers intentionally as part of a planned release. We’ve mentioned this intention several times over the last year, and the deployment of capabilities is now approaching.

 

We’ll let you know when we have enabled this new capability for your OU. At that time, you can add computers to a group and get automatic certificate enrollment to these computers.

 

More Info:

This capability was added due to strong customer interest in lowered costs for certificate management. Based on customer need analysis, there were enough internal-only uses and cost-savings to move forward, even though this may make the UW certificate story a little more complicated. Given how handy an AD integrated CA is, we believe there will be more use cases identified and future capabilities–in fact, there is currently customer interest in exploring three other use cases. More information on these use cases and future capabilities will be coming over the next few months.

 

Do be aware that for UW internal use cases you may need to ask a service to trust the netid-root-CA and netid-issuing-CA in order to leverage the client authentication capability. For example, the Groups Web Service does not currently trust these certificates.

 

If you need to get a copy of the CA certs, they are available at:

http://thrawn.uw.edu/CertEnroll/cracken.netid.washington.edu_netid-issuing-CA.crt

http://thrawn.uw.edu/CertEnroll/madine.netid.washington.edu_netid-root-CA.crt

 

Additional details on the “Computer” certificate:

Validity: 1 year

Renewal: 6 weeks

Private key is not exportable

Minimum key size of 2048

Subject name is based on dnsHostname attribute of AD computer object

 

Additional technical details on the two new certificate authorities:

Both are implemented in a manner such that if we later needed to, we can meet FIPS compliance, although at this time we are not using a HSM module for private key storage. The root CA is designed to be an “offline” CA hosted in Azure, brought online at least once a year to republish the certificate revocation list (CRL). Hosting this CA in Azure allows us to save costs since it is offline most of the time, and their hosting practices are as good or better than ours (e.g. they have rolling audits to meet various regulatory certifications). We are hoping that in the future Microsoft provides a virtual HSM capability for AD-CS integrated with its Azure Key Vault.

 

Brian Arkills

UW Windows Infrastructure Service Manager