Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 27 Next »

SSL Certificates

SSL certificates are digital signatures that websites can use to prove their authenticity and provide their users with privacy, via encryption. Banking websites, Tufts webmail, and many other Tufts services use SSL certificates signed by (CAs) to prove their identity to browsers (which in turn have been preconfigured to trust a limited set of CAs).



Personal Information

Sites or applications that process or access Personal Information must require SSL. Browsers that do not request SSL should be redirected to the SSL port (the entire session - not just the login - must be encrypted). SSL certificates must be signed by a trusted CA. Legacy systems that process or access PI must obtain and deploy a CA-signed certificate as soon as possible.


LDAP (Enterprise Directory or Active Directory Binding)

Sites that use Tufts username and Tufts Password to authenticate users must require SSL. Browsers that do not request SSL should be redirected to the SSL port. New systems should have a CA-signed certificate from the start; any old systems that have self-signed or manufacturer-provided certificates should be phased into valid, CA-signed certificates at the next opportunity. Some websites only encrypt the authentication portion of the connection to save processing power; avoid this temptation, and encrypt the entire session if at all possible.

Self-Signed Certificates

Self-signed certificates are not recommended. Self-signed certificates do allow the connection to be encrypted, but do not provide any guarantee that the encrypted connection is with the correct server. Anyone can create a self-signed certificate that is functionally identical to any other self-signed cert, so there is no guarantee of privacy or authenticity. CA-signed certificates do guarantee that the site is authentic and that the connection is private. If you must use a self-signed certificate on a test system, you should not connect to it from off-campus, because your connection is susceptible to man-in-the-middle attacks and could be intercepted by a third party.

Self-signed certs should not be used on any new production systems. It's highly recommended to build certificate assignment into your deployment process. Old production systems that have self-signed certificates should be phased into CA-signed certificates at the next opportunity.

Get a CA-signed Certificate

Order InCommon certificates

Known Issues with CA-signed Certificates

  • It is important to install the intermediate certificate that comes with any certificate you purchase, especially if the service is taking advantage of Tufts Load Balancers or CNames for the DNS resolution of the service. Without this some devices will detect a break in the certificate chain and will not trust the CA root.
  • Some versions of Android (like JellyBean) currently do not have the latest root CA of Geotrust installed in them and may not trust our signed certificates authored by Geotrust. Tickets have been submitted with both Google and GeoTrust to try to address this.
  • No labels