- Introduction
This document describes the procedures for applying for TLS certificates. TLS certificates are used to sign and encrypt data, especially between servers and clients, sign and encrypt email messages and sign documents and software. HARICA provides these certificates. This ensures reliability.
The procedure for requesting a server certificate has been written with the system and application administrators in mind. An administrator is deemed to have sufficient knowledge about creating a Certificate Signing Request (CSR) and installing the signed certificate. The administrator should also have enough authorization to do so.
The university uses the nameserver system's so-called Certification Authority Authorization (CAA) records. These records indicate which Certificate Authorities (CA’s) we allow to sign certificates for our domains. This prevents malicious parties from applying for certificates for our domains. Our CAA records allow the following CA’s to sign our certificates
- HARICA (provided by LISA)
- Let’s Encrypt
If you need an exception, contact the Service Desk ICT.
- Right to request TLS certificate
All certificates provided by the University of Twente in accordance with the procedures described in this document are free of charge.
Every employee, officially employed by the university, and every student, officially registered accordingly, is entitled to a personal certificate.
Every employee, officially employed by the university, and every student, officially registered accordingly, can request a signed certificate for a server or application they are authorized to administer. This includes computers at home in dorms on the campus of the university.
Certificates can only be requested for hostnames and subdomains registered to the university according to the registry of the Top Level Domain (TLD) the domain is part of. For personal websites, sites of student associations etc. under their own domain, certificates can not be requested. If an association wants to request a certificate according to this procedure, they must transfer the rights to the domain to the university.
Participants in the eScience Grid Computing community are also entitled to eScience, or IGTF-MICS, personal certificates.
- Requesting server certificate
We are in the process of testing the new certificate provider, HARICA.
See the FAQ for more information.
When you need a server certificate, we advise you to use the ACME protocol. Currently, a certificate is valid for one year. The expectation is this will change to 90 days within a couple of years.
- Requesting personal certificate
It is now possible to request a personal certificate.
A personal certificate provides secure email services and enables you to encrypt and digitally sign email communications. It can also be used as a second factor with some systems where username and password are insufficient.
To request a personal certificate, go to the HARICA page. Choose “Academic login”, after which you can log in on the university’s SSO page. You will be taken to HARICA's website if you have already logged in.
See the FAQ for more information.
Do not leave it on a public computer. Do not install the certificate in a browser or email client on a public computer.
- Requesting code signing certificate
Currently, it is not possible to request certificates. The previous supplier has cancelled the contract. A new supplier is selected but setting up procedures and processes will take some time.
When you need a code signing certificate, please contact the Service desk ICT.
- System requirements
To guarantee the safety and security of a system and the transmission of data, a number of requirements have to be adhered to before a system is eligible for a certificate. We monitor webservers by default with the SSL Labs tool from Qualys. The result of a test with this tool should be at least an A.
Furthermore, the Dutch Standardization Forum has drawn up a number of requirements that the university’s servers have to meet. The most important ones are listed below.
- HTTPS; all webservers must use HTTPS for communication. If the server listens on the HTTP port it should redirect to the HTTPS port. Non-webservers must use an equivalent protocol and show the same behavior.
- TLS 1.2; the protocol to be used for encryption must be at least version TLS 1.2.
- HSTS; in order to prevent attackers from interfering with clients making a connection on the HTTP port, HSTS must be used with a max-age directive's value greater than 10368000.
When applying for a certificate, these requirements can be checked before LISA processes the request.
For more information, we suggest looking at the guidelines (in Dutch) from SURF.
