The problems with requesting personal certificates are resolved.
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. These certificates are provided by Sectigo. This ensures reliability. Sectigo certificates are supported by all common browsers and other clients.
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 of creating a Certificate Signing Request (CSR) and installing the signed certificate. The administrator should also have enough authorization to do so.
The university uses so-called Certification Authority Authorization (CAA) records in the nameserver system. These records indicate which Certificate Authorities (CA’s) we allow to sign certificates for our domains. This prevents malicious parties to apply for certificates for our domains. Our CAA records allow the following CA’s to sign our certificates
- Sectigo (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 entitle 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 advise using the ACME protocol. Currently, a certificate is valid for one year. The expectation is, this will change to 90 days by the end of 2024.
If you still want or need to request certificates manually, see below.
Requests for server certificates can be made via the self service portal. Be sure to provide information about your environment. This will help us deliver the signed certificate in a format best suited for your server or application.
The CSR provided has to be in PEM format. The key used to generate the CSR must have a minimum strength of 2048 bits. The hash must comply with SHA-256. The CSR should at least contain the following information:
- C (Country) = NL
- L (Locality) = Enschede
- O (Organization) = University of Twente
- OU (Organizational Unit) = the official English name or abbreviation of your unit
- CN (Common Name) = the hostname for which system the certificate is to be used.
The first three (C, L and O) are fixed and may be adjusted to the correct value during the signing. CN is a required field and contains the primary hostname. OU is optional. You can add Subject Alternative Names (SAN’s) to a maximum of 250 names.
A wildcard in the CN is only possible if you do not use any SAN. We advised against using wildcards. A wildcard is prohibited if the scope becomes too large. A request for *.department.utwente.nl will not be granted. A request for *.studentassociation.utwente.nl is acceptable though.
After the CSR is signed you will receive the signed certificate in the format you requested. Some formats contain the complete chain of certificates. If you install the certificate on your server you only need to install your own certificate and the GÉANT certificate. That certificate is used to sign your certificate. The certificates used to sign the GÉANT certificate are already known in all browsers.
This certificate will be valid for one (1) year by default.
- Requesting personal certificate
A personal certificate provides secure email services, and enables you to encrypt and digitally sign email communications, as well as sign and protect some types of document (but not sign PDF documents). It can also be used as a second factor with some systems where username and password are not sufficient.
To request a personal certificate go to the Sectigo SSO page. Choose “University of Twente”, after which you are can log in on the university’s SSO page. If you have already logged in, you will be taken to the Sectigo website.
Check the name and email address provided. These will be automatically added to the certificate. If these are not correct contact the Service Desk ICT. Do not continue if the information is incorrect.
Select the certificate profile. For normal use select the GÉANT Personal Certificate profile. Then select the Private Key. Currently almost all systems support RSA. Newer systems will also support ECC. It is possible to request one certificate with an RSA key and one with an ECC. You can request a maximum of two certificates with each key type. If you request a third certificate, the oldest one of that type will be invalidated.
Provide a password for the P12 certificate file Sectigo will generate. It will be mailed to you. As it will contain your secret key, anybody having access to your email, either on the server or on the network, will be able to impersonate you.
Remember the password!
Without the password you can not install the certificate in your client.
When you receive the certificate file, store it on a safe and secure medium. 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
If you need your code signed for installation you can request a code signing certificate. These certificates can only be supplied on specific hardware that handles the signing without exporting the certificate itself.
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.