Contents
Recruiting DRAOs
Central administrative team
Who administers the program?
The InCommon Certificate service is managed by UC Berkeley's CalNet team, which oversees Identity and Access Management services for our campus. The five members of the CalNet team have all been granted RAO level permissions (see Chain of Trust section). For any given week, the "on-call" staff person processes certificate requests.
How do customers submit requests?
The CalNet team uses a published mailing list, calnet-pki@lists.berkeley.edu, to accept and process certificate requests.
Instructions to customers making certificate requests are included in our published InCommon Certificate FAQ.
How are requests reviewed/validated as legitimate?
UC Berkeley already had a pre-established program for registering a Security Contact for all campus hosts. As part of implementing the InCommon Certificate program, CalNet team members were given access to the Security Contact Application so that RAO's could look up the Security Contact for any given host. The CalNet RAO forwards the certificate request to the registered Security Contact. Once approved, the CalNet team member uses the InCommon CSM application to enter and review the CSR and approve the certificate.
Central vs. delegated administration
We anticipate some campus customers will continue to send certificate requests directly to the CalNet team, but our hope is that the vast majority of requests can be handled by local, departmental certificate administrators (DRAOs). Please see sections below on our approach to recruiting and training those administrators.
Initial recruitment of delegated administrators
Central IT Staff
The CalNet team began by requesting that the Deputy CIO approve DRAO status for a handful of central IST staff. These staff manage hosts on behalf of other campus departments and for campus-wide services. They were granted permission to approve certificates at the top level .berkeley.edu domain.
Departmental IT Staff
The CalNet team then identified the highest level IT staff in large campus departments like the business school, law school, EECS, etc, asking that they appoint delegated certificate administrators for their departments. We also asked approved departmental administrators to provide us the subdomains/hosts to enroll for that department. See sample letters, here.
We maintain the list of approved departmental administrators in our internal wiki, noting the department name, managerial sponsor, and date the administrator was approved. Our default is to grant DRAO status for 3 years, which is the default certificate length we grant as well.
We will review the list of DRAOs at least annually to remove accounts for employees who have left the university.
Adding DRAOs to the InCommon CSM
Once management has appointed or approved a DRAO, we contact the administrator to request enrollment information. See our sample enrollment letter and screenshots for adding DRAOs to the InCommon CSM.
Ad hoc recruitment of delegated administrators
While we hope to catch as many departments as possible in our initial efforts to recruit departmental administrators, we know we will miss some. When requests come to our central service mailing lists, calnet-pki@lists.berkeley.edu, our response includes a paragraph requesting contact information for a high level manager in that department who could authorize departmental administrators. We check that person's standing via the campus directory and then send the manager our letter to authorize departmental administrators.
Training DRAOs
At UC Berkeley, we require all DRAOs to participate in an in-person training before we approve their DRAO status. Below is an outline of the training and some related documentation. Below is our training outline:
Your responsibility as a DCA
- Only approving certificates legitimately associated with the department(s) for which you are authorized
- Consulting with the CalNet team before issuing wildcard certificates because of the potential security risks
- Maintaining an audit trail for certificate requests, approvals, and renewals. This could be via using an e-mail archive, a ticketing system, or other records of transactions.
Some tips for generating CSRs
- For hosts that may have domain components that start with a number, for example, host.1918.berkeley.edu, the Java keytool may complain when generating keypairs. Use OpenSSL-based techniques instead.
- UCC/SAN certs: use the gencert script (modified for your environment) to simplify the use of OpenSSL.
Using the InCommon CSM tool
- See Delegation Screen Shots
- Detailed information on the tools can be found at the InCommon Certificate Service Support Site.
- We suggest using a common institutional address for all departments delegated so that any certificate bearing the institutional name will have the same Subject address information.
- We have not used some of the more advanced features extensively (custom notifications, self-enrollment, etc.) to keep the initial roll-out simpler and faster until we can judge the need for some of the extra features.
Some questions we have received:
- What about EV certificates? This may become possible in the future via the admin tool.
- What to put in the External requester field? This depends on whether you want the person listed receiving the notices generated at the various stages of certificate provisioning.
- What about wildcard certs? Now that we can generate certs on demand, and use UCC/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 the 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.
- Is there any automated way to issue multiple certs? An API will be needed for this.