Re: InCommon Certificate: Local vetting and management--Summary of Responses

[Martin Manjak <mmanjak () ALBANY EDU>]

Several people were kind enough to reply to my query regarding the
management process used to issue and track certificates after their
institutions decided to enroll in the InCommon certificate service.

Here's a summary of those replies. Each letter corresponds to one
institution's reply to each of the questions. Please note that F is not
using InCommon per se, but a similar consortium with the same CA.
====================================================
1. How do you vet requests for certs?

A. Domains are validated out-of-band prior to requesting a cert.
Currently the org is required to demonstrate administrative control of
the domain by constructing a CNAME record in DNS.

B. A department purchases a subscription, which everything is tied to. A
subscription has one subscriber, who is vetted manually by our staff. We
generally contact the director or dean of the unit requesting the
purchase to confirm identity and permission. Domains are then added to
the subscription and we check those with our central Networking Services
group. All of this is added and managed through the web tool.

C. We were previously using another CA's web system. Using that we had
about ten people across campus, 7 of whom were in IT, who had accounts
allowing them to submit CSRs. We had two people with accounts who could
approve them. Almost all campus servers with certificates are maintained
by IT.

D. Requester is typically a member of our campus wide IT governance
group and fills out a form that includes sign off from the department
manager or equivalent. Presumably the processor would investigate
further if the request came from an unknown entity (student, non-IT
staff, faculty, etc.).

E. We are a small organization so we have 2 people authorized to vet any
cert requests. 

F. The great majority of requests come from the same people, we can
easily verify the domain name that has been requested is "normal" for
the requester. Unusual ones just trigger some manual thought and
occasionally a phone-call to verify the requirement. In general, we
allow any request for a certificate within our top-level domain, and
carefully examine all requests for something outside our domain.


2. What, if any, workflow management tools do you use to track the
status of a request?

A. The vast majority of orgs use the Certificate Manager web interface
for this purpose. A few schools have implemented their own interface via
a documented SOAP-based API.

B. We wrote our own web-based management tool to handle requests,
assignment of names and billing information.

C. With our current volume and the ability to issue 3 year certificates,
email has sufficed. Unless there is an emergency requisition (e.g.
missed certificate expiration, poorly planned go-live), we assume when
we approve the cert in the Certificate Manager that the requester will
get an email message with the link to pick it up in a timely manner. So
far, so good. Since we work closely with the people who issue CSRs, they
know what to expect as far as turn-around time.

D. Currently a single page paper form. A web version is anticipated at
some point.

E. IT staff forward the request to the security team and they provide
the requester the cert based off the CSR that is provided.

F. The CSM seems to have adequate reporting on the status of requests
once they have been entered, and currently turnaround is ~3 hours
anyway, so not much tracking is generally required.


3. Who has the authority to submit the CSR at your institution?

A. That is a local issue.

B. Subscribers submit CSRs with any additional information and we
process them. We have automated the verification, but we still process
the request to Comodo manually. We did build an interface using the API
for automated processing, but we did not go to production with it for
various reasons.

C. The ten or so people who held accounts with our previous CA email the
security team's shared email account. We vet the CSR with openssl,
sometimes with the sender, and submit it to Comodo. We've allowed a few
more people known to us to do this since an account isn't needed but for
the most part, the same people are submitting CSRs to us via email who
were previously submitting CSRs to our former CA's web site.

D. A member of the central IT systems teams. (Our focus is limited to
Academic services).

E. Only our IT staff can request certs.
 
F. The Information Security Manager, and the Information Security
Analyst. We will probably add other members of the Information Security
Office to help cover for holiday periods. We will consider adding a
couple of representatives of the busiest departments, but I suspect
turnover is so low that it isn't worthwhile; we only have ~200
Internet-visible HTTPS servers anyway.


4. Who is responsible for managing/renewing the certificate once issued?

A. The CM provides notifications and a port sweeper to help with this.

B. Management and renewals are the responsibility of the subscriber. We
don't actually offer renewals, we simply issue new certificates.

C. The requester of the certificate. We've also enabled the Certificate
Manager scanning function to alert us of certificates that will expire
soon and will forward the message if it looks like its getting close
with no action taken. When we start issuing user certificates, that will
certainly change and we'll need to roll out a much more sophisticated
system before then.

D. The requester.

E. (No specific response to this question.)

F. The original submitter is responsible for the state of their own
machines and therefore the SSL certs that they have. We are happy to
help to remind them of upcoming expiry, but they are the only ones who
will know if the service using them is still required at any point in
time.




On 12/14/2011 11:32 AM, Martin Manjak wrote:
> We're planning on enrolling in the InCommon certificate program next FY
> and staff here were wondering what vetting and management processes
> other schools who have been using the service may have put in place.


-- 

Martin Manjak
CISSP, GIAC GSEC-G
Information Security Officer
University at Albany
MSC 209 518/437-3813

The University at Albany will never ask you to reveal your password.
Please ignore all such requests.