Certification authority (CA)¶
Zentyal uses OpenSSL® [1] for the management of the Certification Authority and the life cycle of the issued certificates issued.
[1] | http://www.openssl.org/ |
Certification Authority configuration with Zentyal¶
In Zentyal, the Certification Authority module is self-managed, which means that it does not need to be enabled in Module status. However, you have to initialize the CA to make the functionality of the module available to other services.
Go to Organization Name and Days to expire fields. Optionally, it is possible to specify the Country code (a two-letter acronym following the ISO-3166-1 standard [2]), City and State.
and you will find the form to create the CA. You are requested to fill in theWhen setting the expiration date, take into account that all certificates issued by this CA will be revoked upon expiration, stopping all services depending on those certificates.
Once the CA has been initialised, you will be able to issue certificates. The required data are the Common Name of the certificate and the Days to expire. This last field is limited by the fact that no certificate can be valid for a longer time than the CA. In case you are using the certificate for a service such as a mail server, the Common Name of the certificate should match the domain name of that server. For example, if you are using the domain name hq.zentyal.org to access your mail server in Zentyal, you will need a certificate with the same Common Name. In case you are setting a user certificate, the Common Name will usually be the user’s email address.
Optionally, you could set Subject Alternative Names [3] for the certificate. These are useful when setting common names to a certificate, for instance an email address when signing email messages.
Once the certificate is issued, it will appear in the list of certificates and it will be available for the administrator and for the rest of modules. Through the certificate list you can perform several actions on the certificates:
- Download the public key, private key and the certificate.
- Renew the certificate.
- Revoke the certificate.
- Reissue a previously revoked or expired certificate.
The package with the keys contains also a PKCS12 file with the private key and the certificate and it can be installed directly into other programs such as web browsers, mail clients, etc.
If you renew a certificate, the current certificate will be revoked and a new one with the new expiration date will be issued. And if you renew the CA, all certificates will be renewed with the new CA trying to keep the old expiration date. If this is not possible because it is after the date of expiry of the CA, then the date of expiration is set as the one of the CA.
If you revoke a certificate you will not be able to use it anymore as this action is permanent and it can not be undone. Optionally, you can select the reason of the certificate revocation:
- unspecified: reason non specified,
- keyCompromise: the private key has been compromised,
- CACompromise: the private key for the certification authority has been compromised,
- affilliationChanged: the issued certificate has changed its affiliation to another certification authority from other organization,
- superseded: the certificate has been renewed and it is now replaced by a new one,
- cessationOfOperation: the certification authority has ceased its operations,
- certificateHold: certified suspended,
- removeFromCRL: currently unimplemented, it provides delta CRLs support, that is, lists of certificates whose revoked status has changed.
When a certificate expires all the modules are notified. The expiration date of each certificate is automatically checked once a day and every time you access the certificate list page.
[2] | http://en.wikipedia.org/wiki/ISO_3166-1 |
[3] | For more information about subject alternative names, visit http://www.openssl.org/docs/apps/x509v3_config.html#Subject_Alternative_Name |
Services Certificates¶
On
you can find the list of Zentyal modules using certificates for their operation. Each module generates its own self-signed certificates, but you can replace them with others issued by your CA.You can generate a certificate for each service by defining its Common Name. If a previous certificate with the name does not exist, the CA will create it automatically.
Once enabled, you need to restart the service to force the module to use the new certificate. This also applies if you renew a certificate for a module.
As mentioned before, to use the secure version of multiple protocols (like mail) it is important that the name that appears in the “Common name” of the certificate matches with the name requested by the client. For example, if the Common name of your mail certificate is hq.zentyal.org and the client types in his client mail.hq.zentyal.org, the client will show a security alert (or reject the connection) and the certificate will be considered as a not valid one.
Service certificate checklist:
- The Certification Authority is created, service module is installed.
- You have created a DNS name for the service (A or CNAME) that the client can resolve, for example ‘mail.hq.zentyal.org’.
- You issue a certificate for the specific service, let’s say ‘Mail’ with Common Name ‘mail.hq.zentyal.org’, and after that you enable the certificate you should be able to see it going to .
- You have enabled the secure protocols for mail.
- You have imported the CA certificate (not the service certificate) on the client’s system, or client application, let’s say the mail client.
- User configures mail as mail.hq.zentyal.org.
- User is able to resolve the DNS to an IP address, the Common Name perfectly matches what he/she typed “mail.hq.zentyal.org”, and the certificate presented by the service is signed by a trusted Authority.
- User’s application is able to start a secure session without displaying any security warnings