Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

Version 1 Next »

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. cert-auth will then approve the certificate.


Turn-around Time

CUIT 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 can be obtained for a 1 or 2 year period.  Warning emails will be sent by InCommon to the certificate owners as the expiration date nears.  For CUIT systems, a Service Now incident will be automatically opened to track the certificate renewal.  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.

 


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

 

  • No labels