Client or S/MIME Certificates
Secure/Multipurpose Internet Mail Extensions (S/MIME) or Client certificates work much in the same way TLS certificates work using the TLS protocol to provide authentication by inspecting the contents of an encrypted digital identity submitted by the client.
Client certificates are issued to individuals and have been traditionally used with signing and encrypting e-mail. Client certificates associate an individual’s University approved e-mail address to a public/private cryptographic key pair that he/she personally controls.
The University supports the use of S/MIME certificates to digitally sign and encrypt e-mail on the following operating systems and e-mail clients:
- OS X 10.12 and later
- Linux and other UNIX systems
- Windows Vista and later
- iOS 10 and later.
- Apple Mail
- Thunderbird (Linux/UNIX, OS X and Windows)
- Outlook (OS X and Windows)
- Mail on iOS
Outlook Web Access (OWA/ HawkMail) used on Internet Explorer 9 or later should support Client Certificates. OWA does not support Client Certificates on other web browsers.
Note: Some third-party applications on Android devices can use S/MIME certificates; however, ITS does not officially support these applications for use with our mail servers.
End-users can request client certificates in one of the following two ways:
1. Self -Enrollment by Administrator Invite
Involves sending invitation e-mails to end-users previously added to CM (Certificate Manager). The Administrators can provision end user accounts in the CM, and once completed, they send on an invite from the CM interface. The invitation e-mail will contain a validation link and instructions for the end-users to download and install their certificates.
2. Self-Enrollment of End-Users by Access Code
Involves directing the end-users to apply for their own client certificate by accessing the self-enrollment form; for details see "End-User S/MIME Certificate Request" section. The Administrator (S/MIME DRAO) informs the end-user of their department specific access code to which the end-user belongs. This should be done by out-of-band communication such as e-mail or phone.
NOTE *InCommon Certificate Manager creates a copy of each end-user’s certificate which it saves on the server. This duplicate certificate is protected in two ways:
- The key pair of each end-user's certificate is encrypted by a master public key.
- Password protected with an administrator set password. The end-user will be asked for this password every time they wish to download a certificate.
The CM stores the individual private keys of end-user’s client certificates so that they can be retrieved at a later date by the administrator or end-user. Due to the highly sensitive and confidential nature of this feature, all end-users' key pairs are stored in encrypted form so that they cannot be easily stolen or compromised.
Each end-user’s key pair is encrypted using a ‘master’ public key that is stored by CM. In order to decrypt this end-user's key pair the administrator must paste the corresponding departmental ‘master’ private key into the space provided.
DRAOs can set a password (PIN) to protect access to private key in the .p12 file as well. The DRAO is able to bypass the PIN but you should be aware that NOT all programs will allow the certificate to be imported if they do so. (PINs may be 7 characters maximum).
Outlook Web Access (OWA) used on Internet Explorer 9 will support Client Certificates. OWA does not support Client Certificates on other web browsers.
Note: Some third-party applications ( e.g. Touchdown) on Android devices can use S/MIME certificates; however, the ISPO does not officially support these applications for use with the University e-mail systems.