mirror of
https://github.com/YunoHost/doc.git
synced 2024-09-03 20:06:26 +02:00
Remove old certmanager page which was ~only relevant for migrating away from the old letsencrypt app, now it's superseded by the 'certificate' page
This commit is contained in:
Alexandre Aubin
parent
15ecef3d84
commit
ab0c6ee1af
2 changed files with 0 additions and 364 deletions
185
certmanager.md
185
certmanager.md
|
|
@ -1,185 +0,0 @@
|
||||||
|
|
||||||
Certificate management
|
|
||||||
======================
|
|
||||||
|
|
||||||
Managing certificates with Yunohost
|
|
||||||
-----------------------------------
|
|
||||||
|
|
||||||
The main feature of the certificate manager is to allow you to install Let's
|
|
||||||
Encrypt certificate on your domains without pain. You can use it from the web
|
|
||||||
administration (*SSL certificate* on a given domain info page), or from the
|
|
||||||
command line with `yunohost domain cert-status`, `cert-install` and
|
|
||||||
`cert-renew`.
|
|
||||||
|
|
||||||
#### What is required to be able to have a Let's Encrypt certificate ?
|
|
||||||
|
|
||||||
Your server needs to be reachable from the rest of Internet on port 80 (and
|
|
||||||
443), and make your `domain.tld` points to your server's public IP in your DNS
|
|
||||||
configuration. See [this documentation](diagnostic_en) if you need help.
|
|
||||||
|
|
||||||
#### Will my certificate be automatically be renewed ?
|
|
||||||
|
|
||||||
Yes. Right now, Let's Encrypt certificates are valid 90 days. A cron job will
|
|
||||||
run every day and attempt to renew any certificate that will expire in less than
|
|
||||||
15 days. An email will be sent to the root user if a renewal fails.
|
|
||||||
|
|
||||||
#### I want/need to use a certificate from a different CA than Let's Encrypt.
|
|
||||||
|
|
||||||
This cannot be done automatically for now. You will need to manually create a
|
|
||||||
Certificate Signing Request (CSR) to be given to your CA, and manually import
|
|
||||||
the certificate you get from it. Check out [this page](certificate) for more
|
|
||||||
info. This process might be made easier by Yunohost in the future.
|
|
||||||
|
|
||||||
Migration procedure
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
> Because of the current [rate limits](https://letsencrypt.org/docs/rate-limits/)
|
|
||||||
on new Let's Encrypt certificate emissions, we recommend that you **do not
|
|
||||||
migrate** to the new built-in management feature **as long as you don't need to**.
|
|
||||||
This is especially true for nohost.me / noho.st users (and other domains services
|
|
||||||
sharing a common subdomain). If too many people migrate during the same period
|
|
||||||
of time, you might get stuck with a self-signed certificate for a few days !
|
|
||||||
|
|
||||||
#### I used the *letsencrypt_ynh* app
|
|
||||||
|
|
||||||
You will be asked to uninstall the app before being able to use the new
|
|
||||||
management feature. You can do it from the web administration interface, or from
|
|
||||||
the command line with :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
yunohost app remove letsencrypt
|
|
||||||
yunohost domain cert-install
|
|
||||||
```
|
|
||||||
|
|
||||||
Be aware that the first command will revert your domains to self-signed
|
|
||||||
certificate. The second command will attempt to reinstall a Let's Encrypt
|
|
||||||
certificate on all your domains which have a self-signed certificate.
|
|
||||||
|
|
||||||
|
|
||||||
#### I manually installed my Let's Encrypt certificates
|
|
||||||
|
|
||||||
You should go in your nginx configuration, and remove the `letsencrypt.conf` (or
|
|
||||||
whatever you called the file containing the `location
|
|
||||||
'/.well-known/acme-challenge'` block) for each of your domains. Also remove the symlink
|
|
||||||
to your current certificates :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
rm /etc/yunohost/certs/your.domain.tld/key.pem
|
|
||||||
rm /etc/yunohost/certs/your.domain.tld/crt.pem
|
|
||||||
```
|
|
||||||
|
|
||||||
Then run :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
yunohost domain cert-install your.domain.tld --force --self-signed
|
|
||||||
yunohost domain cert-install your.domain.tld
|
|
||||||
```
|
|
||||||
|
|
||||||
for each of your domains you want a Let's Encrypt certificate.
|
|
||||||
|
|
||||||
Finally, remove your certificate renewer cron job in `/etc/cron.weekly/`, then backup and remove you `/etc/letsencrypt/` folder.
|
|
||||||
|
|
||||||
Troubleshooting
|
|
||||||
---------------
|
|
||||||
|
|
||||||
#### Admin interfaces says the letsencrypt app is installed, but it's not, and I can't access the certificate management interface !
|
|
||||||
|
|
||||||
Make sure you refresh the cache of your browser (Ctrl + Shift + R on Firefox),
|
|
||||||
and report the issue on the forum or on the bugtracker. You can work around the
|
|
||||||
issue by using `yunohost domain cert-install your.domain.tld` from the command
|
|
||||||
line.
|
|
||||||
|
|
||||||
#### I tried to uninstall the letsencrypt app, but it broke my nginx conf !
|
|
||||||
|
|
||||||
Sorry about that. Some user reported that this happens when the uninstallation
|
|
||||||
script fails to find a backup of your self-signed certificate. Running `yunohost
|
|
||||||
domain cert-install` should work anyway...
|
|
||||||
|
|
||||||
#### I get "Too many certificates already issued", what's happening ?
|
|
||||||
|
|
||||||
Currently, Let's Encrypt has a rate limit of issuing no more than 20 new
|
|
||||||
certificates by period of 7 days for a given subdomains. For example, `nohost.me`
|
|
||||||
and `noho.st` are already considered as subdomains themselves, meaning all users
|
|
||||||
of the nohost.me / noho.st service share the same common limit. According to
|
|
||||||
Let's Encrypt, this applies for *new* certificates, but not for renewals or
|
|
||||||
duplicates. If you encounter this limit, there isn't much to do except retrying
|
|
||||||
a few days later.
|
|
||||||
|
|
||||||
#### Certificate installation fails, says "Wrote file to 'some path', but couldn't download 'some url'" !
|
|
||||||
|
|
||||||
This should be fixed in the future, but for now you might need to manually add the
|
|
||||||
following line in your `/etc/hosts` :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
127.0.0.1 your.domain.tld
|
|
||||||
```
|
|
||||||
|
|
||||||
About certificates and Let's Encrypt
|
|
||||||
------------------------------------
|
|
||||||
|
|
||||||
#### What is HTTPS ? What's the point of SSL certificates ?
|
|
||||||
|
|
||||||
HTTPS is the secure version of the HTTP protocol, which describes how a client
|
|
||||||
(e.g. a web browser) and a server (e.g. nginx running on your Yunohost
|
|
||||||
instance) can talk to each other. HTTPS heavily relies on [asymmetric
|
|
||||||
cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) to achieve
|
|
||||||
two things :
|
|
||||||
- confidentiality, meaning that an attacker will not be able to decrypt the content of the communication if it is intercepted ;
|
|
||||||
- server's identification, meaning that a server can prove he is who it says it is, thus protecting against [man-in-the-middle attacks](https://en.wikipedia.org/wiki/Man-in-the-middle_attack).
|
|
||||||
|
|
||||||
SSL certificates is the technology used for server to prove their identity. The
|
|
||||||
whole process relies on trust in third parties called Certification Authorities
|
|
||||||
(CA), whose role is to verify the server identity (e.g. that a given machine
|
|
||||||
effectively controls the domain `ilikecoffee.com`) before delivering
|
|
||||||
[cryptographic certificates](https://en.wikipedia.org/wiki/Public_key_certificate).
|
|
||||||
|
|
||||||
#### Why do browsers complain about self-signed certificates ?
|
|
||||||
|
|
||||||
Self-signed certificates are, as their name says, self-signed, meaning that you
|
|
||||||
were your own certification authority in the process. Such a certificate does
|
|
||||||
not allow to verify your server's identity, since it could have easily been
|
|
||||||
generated by an attacker on its own, attempting to perform man-in-the-middle
|
|
||||||
attacks.
|
|
||||||
|
|
||||||
#### What's up with Let's Encrypt ?
|
|
||||||
|
|
||||||
Historically, the process of verifying the identity of a server often required
|
|
||||||
human intervention, time and money.
|
|
||||||
|
|
||||||
In 2015, Let's Encrypt, developped a protocol called
|
|
||||||
[ACME](https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment),
|
|
||||||
which allows to automatically verify that a machine controls a domain, and deliver
|
|
||||||
certificates for free, drastically reducing the cost of setting up a SSL
|
|
||||||
certificate.
|
|
||||||
|
|
||||||
#### How does Let's Encrypt works ?
|
|
||||||
|
|
||||||
To verify your server's identity and deliver the certificate, Let's Encrypt uses
|
|
||||||
the [ACME
|
|
||||||
protocol](https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment). It
|
|
||||||
basically works as follow (it's simplified, but you'll get the idea) :
|
|
||||||
- A program running on your server contacts the Let's Encrypt CA server, ask for
|
|
||||||
a certificate for domain `ilikecoffee.com`.
|
|
||||||
- The Let's Encrypt CA server generates a random string such as `A84F2D0B`, and
|
|
||||||
tells the program on your server to prove it operates the domain
|
|
||||||
`ilikecoffee.com` by making the URI `http://ilikecoffee.com/.well-known/acme-challenge/A84F2D0B`
|
|
||||||
accessible.
|
|
||||||
- The program on your server edit/creates files accordingly.
|
|
||||||
- The Let's Encrypt CA server attempt to access the URI. If it works, then it
|
|
||||||
concludes the program indeed operates the domain `ilikecoffee.com`. It
|
|
||||||
delivers a certificate.
|
|
||||||
- The program on your server obtains the certificate and setups it.
|
|
||||||
|
|
||||||
#### Do we really need Certification Authorities ?
|
|
||||||
|
|
||||||
The reliance on Certification Authorities can be criticized, as they represent
|
|
||||||
points of failure in the security scheme. Some trusted CAs have been found to
|
|
||||||
issue rogue certificates in the past, sometimes with critical implications
|
|
||||||
[[1](http://www.darkreading.com/endpoint/authentication/fake-google-digital-certificates-found-and-confiscated/d/d-id/1297165),
|
|
||||||
[2](https://reflets.info/microsoft-et-ben-ali-wikileaks-confirme-les-soupcons-d-une-aide-pour-la-surveillance-des-citoyens-tunisiens/)].
|
|
||||||
|
|
||||||
Alternatives have been proposed, such as
|
|
||||||
[DANE/DNSSEC](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities),
|
|
||||||
which is based on the DNS system does not require certification authorities.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,179 +0,0 @@
|
||||||
|
|
||||||
Gestion du certificat
|
|
||||||
======================
|
|
||||||
|
|
||||||
Gérer les certificats avec YunoHost
|
|
||||||
-----------------------------------
|
|
||||||
|
|
||||||
La fonctionnalité principale du gestionnaire de certificat est de permettre l'installation
|
|
||||||
de certificat Let's Encrypt facilement sur vos domaines. Vous pouvez l'utiliser depuis
|
|
||||||
l'interface d'admin web (*Certificat SSL* sur la page d'info d'un domaine), ou avec
|
|
||||||
la ligne de commande avec `yunohost domain cert-status`, `cert-install` et `cert-renew`.
|
|
||||||
|
|
||||||
#### De quoi ai-je besoin pour avoir un certificat Let’s Encrypt ?
|
|
||||||
|
|
||||||
Votre serveur doit être accessible depuis le reste d'Internet sur le port 80 (et 443),
|
|
||||||
et le DNS de votre `nom.de.domaine.tld` doit être correctement configuré (i.e. le
|
|
||||||
domaine doit pointer sur l'IP publique de votre serveur). Vous pouvez vous aider
|
|
||||||
de [cette documentation](diagnostic_fr) si vous avez besoin d'aide.
|
|
||||||
|
|
||||||
#### Est-ce que mon certificat sera renouvelé automatiquement ?
|
|
||||||
|
|
||||||
Oui. À l'heure actuelle, les certificats Let's Encrypt sont valides pendant 90 jours.
|
|
||||||
Une tâche automatique (cron job) sera exécutée tous les jours pour renouveler les certificats
|
|
||||||
qui expirent dans moins de 15 jours. Un email sera envoyé à l'utilisateur root si le
|
|
||||||
renouvellement échoue.
|
|
||||||
|
|
||||||
#### Je souhaite/j’ai besoin d’utiliser un certificat d’une autre autorité de certification
|
|
||||||
|
|
||||||
Ceci n'est pas géré automatiquement pour le moment. Il vous faudra créer manuellement
|
|
||||||
une demande de signature de certificat (CSR) qui devra être donné à votre CA, puis importer
|
|
||||||
le certificat obtenu. Plus d'informations sur [cette page](certificate_fr). Ce processus sera
|
|
||||||
peut-être rendu plus facile par YunoHost dans le futur.
|
|
||||||
|
|
||||||
Procédure de migration
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
> À cause des [limitations actuelles](https://letsencrypt.org/docs/rate-limits/)
|
|
||||||
sur la fréquence d'émissions de nouveaux certificats Let's Encrypt, nous recommandons que
|
|
||||||
vous ne **migriez pas** vers cette nouvelle fonctionnalité **tant que vous n'en avez pas besoin**.
|
|
||||||
C'est en particulier vrai pour les utilisateurs de nohost.me / nohost.st (et d'autres services de
|
|
||||||
nom de domaine gratuit qui partagent un sous-domaine commun). Si trop de monde migrent
|
|
||||||
pendant la même période, vous vous retrouverez peut-être bloqué avec un certificat auto-signé
|
|
||||||
pendant quelques jours !
|
|
||||||
|
|
||||||
#### J’ai utilisé l’application *letsencrypt_ynh*.
|
|
||||||
|
|
||||||
Il vous sera demandé de désinstaller l'application pour pouvoir utiliser la nouvelle gestion
|
|
||||||
de certificat. Vous pouvez procéder à la désinstallation depuis l'interface web, ou bien depuis
|
|
||||||
la ligne de commande avec :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
yunohost app remove letsencrypt
|
|
||||||
yunohost domain cert-install
|
|
||||||
```
|
|
||||||
|
|
||||||
Soyez conscients que la première commande devrait remettre en place des certificats
|
|
||||||
auto-signés sur vos domaines. La deuxième commande tentera ensuite d'installer un certificat
|
|
||||||
Let's Encrypt sur chacun de vos domaines ayant un certificat auto-signé.
|
|
||||||
|
|
||||||
#### J’ai installé mes certificats Let’s Encrypt manuellement
|
|
||||||
|
|
||||||
Il vous faut aller dans la configuration nginx et retirer les fichiers `letsencrypt.conf` (ou le nom que
|
|
||||||
vous lui avez donné et qui contient un bloc `location '/.well-known/acme-challenge'`) pour chacun
|
|
||||||
de vos domaines. Retirez les liens symboliques vers vos certificats actuels :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
rm /etc/yunohost/certs/your.domain.tld/key.pem
|
|
||||||
rm /etc/yunohost/certs/your.domain.tld/crt.pem
|
|
||||||
```
|
|
||||||
|
|
||||||
Puis tapez les commandes suivantes :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
yunohost domain cert-install your.domain.tld --force --self-signed
|
|
||||||
yunohost domain cert-install your.domain.tld
|
|
||||||
```
|
|
||||||
|
|
||||||
pour chacun des domaines pour lesquels vous souhaitez avoir un certificat Let's Encrypt.
|
|
||||||
|
|
||||||
Finalement, supprimez la tâche automatique (certificateRenewer) dans `/etc/cron.weekly/`,
|
|
||||||
et backupez puis supprimez le répertoire `/etc/letsencrypt/`.
|
|
||||||
|
|
||||||
Dépannage
|
|
||||||
---------------
|
|
||||||
|
|
||||||
#### L’interface d’admin bloque l’accès à l’interface de gestion du certificat en prétendant que l’app letsencrypt est installée, pourtant elle n’est pas là !
|
|
||||||
|
|
||||||
Assurez-vous que le cache du navigateur est bien rafraîchi (Ctrl + Shift + R sur Firefox).
|
|
||||||
Si cela ne résous pas le problème, rapportez votre expérience sur le bugtracker ou le forum.
|
|
||||||
Vous pouvez contourner le problème en utilisant la commande :
|
|
||||||
`yunohost domain cert-install your.domain.tld`.
|
|
||||||
|
|
||||||
#### J’ai essayé de désinstaller l’application Let’s Encrypt, mais cela a cassé ma configuration nginx !
|
|
||||||
|
|
||||||
Désolé. Quelques utilisateurs ont rapporté que cela arrive lorsque le script de désinstallation ne trouve pas
|
|
||||||
de backup des certificats auto-signés. Utiliser `yunohost domain cert-install` devrait tout de même fonctionner…
|
|
||||||
|
|
||||||
#### J’obtiens "Too many certificates already issued", que se passe-t-il ?
|
|
||||||
|
|
||||||
Pour l'instant, Let's Encrypt a mis en place un taux limite d'émission de certificat, qui
|
|
||||||
est de 20 nouveaux certificats pendant une période de 7 jours pour un sous-domaine donné.
|
|
||||||
Par exemple, les domaines `nohost.me` et `noho.st` sont considérés comme des sous-domaines
|
|
||||||
(des domaines `me` et `st`). ce qui veut dire que tous les utilisateurs du service nohost.me / noho.st
|
|
||||||
partagent une même limite commune. D'après Let's Encrypt, ceci s'applique aux *nouveaux* certificats,
|
|
||||||
mais pas aux renouvellements ou duplications. Si vous rencontrez ce message, il n'y a donc pas grand
|
|
||||||
chose à faire d’autre que ré-essayer dans quelques heures/jours.
|
|
||||||
|
|
||||||
#### L’installation du certificat échoue avec "Wrote file to 'un chemin', but couldn't download 'une url'" !
|
|
||||||
|
|
||||||
Cela devrait être réparé dans le futur, mais pour le moment vous pouvez tenter d'ajouter la ligne suivante
|
|
||||||
au fichier `/etc/hosts` du serveur :
|
|
||||||
|
|
||||||
```bash
|
|
||||||
127.0.0.1 your.domain.tld
|
|
||||||
```
|
|
||||||
|
|
||||||
À propos des certificats et de Let’s Encrypt
|
|
||||||
------------------------------------
|
|
||||||
|
|
||||||
#### Qu’est-ce que HTTPS ? À quoi servent les certificats SSL ?
|
|
||||||
|
|
||||||
HTTPS est la version sécurisée du protocole HTTP, qui décrit comment un client
|
|
||||||
(par ex. votre navigateur web) et un serveur (par ex. nginx qui tourne sur votre instance
|
|
||||||
YunoHost) peuvent discuter entre eux. HTTPS s'appuie fortement sur la [cryptographie
|
|
||||||
asymmétrique](https://en.wikipedia.org/wiki/Public-key_cryptography) pour garantir
|
|
||||||
deux choses :
|
|
||||||
- la confidentialité, ce qui veut dire qu'un attaquant ne sera pas capable de déchiffrer le contenu d'une communication si elle est interceptée ;
|
|
||||||
- l'identification du serveur, ce qui veut dire qu'un serveur peut et doit prouver qui il prétend être, dans le but d'éviter les [attaques man-in-the-middle](https://en.wikipedia.org/wiki/Man-in-the-middle_attack).
|
|
||||||
|
|
||||||
Les certificats SSL sont utilisés par les serveurs pour prouver leur identité.
|
|
||||||
Le processus général repose sur la confiance en des tiers, appelés Autorité
|
|
||||||
de Certification (CA), dont le rôle est de vérifier l'identité d'un serveur (par ex.
|
|
||||||
qu'une machine donnée contrôle bien le domaine `jaimelecafe.com`) avant
|
|
||||||
de délivrer des [certificats cryptographiques](https://en.wikipedia.org/wiki/Public_key_certificate).
|
|
||||||
|
|
||||||
#### Pourquoi est-ce que les navigateurs se plaignent de mon certificat auto-signé ?
|
|
||||||
|
|
||||||
Les certificats auto-signés sont, comme leur nom l'indique, auto-signés, ce qui veut
|
|
||||||
dire que le serveur était sa propre autorité de certification lorsqu'il a créé le certificat.
|
|
||||||
Un tel certificat ne permet pas de vérifier et garantir l'identité du serveur, puisqu'il
|
|
||||||
aurait tout aussi pu être généré par un attaquant de son côté, dans le but de réaliser
|
|
||||||
une attaque man-in-the-middle.
|
|
||||||
|
|
||||||
#### Que se passe-t-il avec Let’s Encrypt ?
|
|
||||||
|
|
||||||
Historiquement, le processus de vérification de l'identité des serveurs demandait une
|
|
||||||
intervention humaine, donc du temps et de la monnaie.
|
|
||||||
|
|
||||||
En 2015, Let's Encrypt a développé un protocole nommé
|
|
||||||
[ACME](https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment),
|
|
||||||
qui permet de vérifier automatiquement qu'une machine contrôle un domaine, et de
|
|
||||||
délivrer un certificat gratuitement, réduisant drastiquement le coût de mise en place
|
|
||||||
d'un certificat SSL.
|
|
||||||
|
|
||||||
#### Comment fonctionne Let’s Encrypt ?
|
|
||||||
|
|
||||||
Pour vérifier l'identité de votre serveur et délivrer un certificat, Let's Encrypt utilise
|
|
||||||
le [protocole ACME](https://en.wikipedia.org/wiki/Automated_Certificate_Management_Environment).
|
|
||||||
Il fonctionne grosso-modo de la manière suivante (simplifiée, mais vous comprendrez l'idée) :
|
|
||||||
- Un programme tourne sur votre serveur et contacte l'autorité de certification Let's Encrypt et
|
|
||||||
lui demande un certificat pour le domaine `jaimelecafe.com`.
|
|
||||||
- L'autorité de certification Let's Encrypt génère une chaîne de caractères aléatoire comme `A84F2D0B`, et
|
|
||||||
dit au programme sur votre serveur de prouver qu'il gère le domaine `jaimelecafe.com` en rendant l'URI
|
|
||||||
`http://jaimelecafe.com/.well-known/acme-challenge/A84F2D0B` accessible.
|
|
||||||
- Le programme sur votre serveur créé/modifie des fichiers en conséquence.
|
|
||||||
- La CA Let's Encrypt tente d'accéder à l'URI. Si cela fonctionne, elle conclue que le programme contrôle
|
|
||||||
bien le domaine `jaimelecafe.com`, et lui délivre un certificat.
|
|
||||||
- Le programme sur votre serveur récupère le certificat et le met en place.
|
|
||||||
|
|
||||||
#### A-t-on vraiment besoin des autorités de certification ?
|
|
||||||
|
|
||||||
La dépendance aux autorités de certification peut être critiquée, car elles constituent des points centraux
|
|
||||||
vulnérables dans le schéma de sécurité. Certaines autorités ont été reconnues coupable d'avoir délivré
|
|
||||||
de faux certificats par le passé, parfois avec des implications sérieuses et très concrètes.
|
|
||||||
[[1](http://www.darkreading.com/endpoint/authentication/fake-google-digital-certificates-found-and-confiscated/d/d-id/1297165),
|
|
||||||
[2](https://reflets.info/microsoft-et-ben-ali-wikileaks-confirme-les-soupcons-d-une-aide-pour-la-surveillance-des-citoyens-tunisiens/)].
|
|
||||||
|
|
||||||
Des alternatives ont été proposées, comme [DANE/DNSSEC](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities),
|
|
||||||
qui repose sur les DNS et ne nécessite pas d'autorité de certification.
|
|
||||||
Loading…
Add table
Reference in a new issue