SSL Certificate Policy

What is covered by this policy?

This policy covers all SSL certificates signed by the CUIT Certificate Authority (cert-auth).

Who is cert-auth?

The cert-auth service is provided by CUIT.

Who is responsible for what?

Clients wishing to run SSL services must contact the system administrator for their system to request an SSL certificate. For any service running on a CUIT host, the system or application administrators are responsible for generating the private/public keypair and submitting the CSR to Service Now via https://www1.columbia.edu/sec/acis/ssl/request.shtml. For services running on non-CUIT hosts, the system administrator of that host shall submit the CSR via https://www1.columbia.edu/sec/acis/ssl/request.shtml.

Once the certificate is submitted via the web-form, cert-auth will submit the CSR to InCommon. InCommon, will ensure that the signature length is (SHA2) and that the key length is up to standard. Currently the key length has to be = or larger than 2048 bits. The cert-auth will then approves the certificate.

Turn-around Time

will sign CSRs and configure keys/certificates, as needed, within 5 business days of their request. If new certificates for non-columbia.edu domains are requested, requests will take longer (generally 5 business days longer) since domain owners will need to authorize InCommon to allow CUIT to sign certificates for that domain.

How long are certificates valid?

Certificates comply with industry standards and remain valid for one year from their issuance date. Warning emails will be sent by InCommon to the certificate owners as the expiration date nears.  For CUIT systems managed by the Systems Sourcing and Engineering Team, a Service Now incident will be automatically opened to track the certificate renewal.  For other CUIT Systems, the Client Services group will manage those certificates in collaboration with the Service Owners.

Exceptions:

CUIT assumes no responsibility for the expiration of certificates on non-CUIT systems.  It is the certificate owner’s responsibility to request a new cert when needed.  For Certs which are for non CUIT Systems, expiration notices are not processed as the certificate owner also receives the request and can renew if needed.

SSL Termination at F5

For Systems behind the F5 Load balancers, SSL termination occurs at the F5 where wildcard certs are utilized.

Reusing CSRs

Certificate Signing Requests (CSR) shall not be reused. Users must generate and submit new CSRs whenever certificates are renewed.

Reusing Private Keys

Private keys shall not be reused. Users must generate new private keys whenever certificates are renewed.

Reusing Private Key Passphrases

Private key passphrases shall not be reused.

Information to provide when requesting a certificate

• Common name
• Type, if applicable (regular, wildcard, multi-domain)
• External requester email address (renewal notices will be sent to this address)
• Expected certificate name

Domain validation