tuto2: Ready
This commit is contained in:
parent
a3657c4356
commit
eff54b1fa0
14
.drone.yml
14
.drone.yml
|
|
@ -120,12 +120,9 @@ steps:
|
|||
image: pandoc/latex:3.1.0
|
||||
commands:
|
||||
- sed -i s/v3.12/v3.14/ /etc/apk/repositories
|
||||
- apk add --no-cache make ttf-linux-libertine
|
||||
- apk add --no-cache make ttf-linux-libertine ttf-inconsolata
|
||||
- tlmgr update --self
|
||||
- tlmgr install enumitem environ etoolbox preprint sectsty selnolig tcolorbox titling
|
||||
- wget -O /tmp/FantasqueSansMono-Normal.tar.gz https://github.com/belluzj/fantasque-sans/releases/download/v1.8.0/FantasqueSansMono-Normal.tar.gz
|
||||
- mkdir /usr/share/fonts/fantasque-sans-mono
|
||||
- tar xf /tmp/FantasqueSansMono-Normal.tar.gz -C /usr/share/fonts/fantasque-sans-mono OTF/ TTF/ --strip-component=1
|
||||
- tlmgr install enumitem environ etoolbox pdfcol preprint sectsty selnolig tcolorbox tikzfill titling
|
||||
- mkdir dist
|
||||
- make -C tutorial/ansible
|
||||
- mv tutorial/ansible/tutorial-2.pdf dist/tutorial-2-${DRONE_TAG##srs20??-tutorial2-}.pdf
|
||||
|
|
@ -175,12 +172,9 @@ steps:
|
|||
image: pandoc/latex:3.1.0
|
||||
commands:
|
||||
- sed -i s/v3.12/v3.14/ /etc/apk/repositories
|
||||
- apk add --no-cache make ttf-linux-libertine
|
||||
- apk add --no-cache make ttf-linux-libertine ttf-inconsolata
|
||||
- tlmgr update --self
|
||||
- tlmgr install enumitem environ etoolbox preprint sectsty selnolig tcolorbox titling
|
||||
- wget -O /tmp/FantasqueSansMono-Normal.tar.gz https://github.com/belluzj/fantasque-sans/releases/download/v1.8.0/FantasqueSansMono-Normal.tar.gz
|
||||
- mkdir /usr/share/fonts/fantasque-sans-mono
|
||||
- tar xf /tmp/FantasqueSansMono-Normal.tar.gz -C /usr/share/fonts/fantasque-sans-mono OTF/ TTF/ --strip-component=1
|
||||
- tlmgr install enumitem environ etoolbox pdfcol preprint sectsty selnolig tcolorbox tikzfill titling
|
||||
- mkdir dist
|
||||
- make -C tutorial/nat
|
||||
- mv tutorial/nat/tutorial.pdf dist/tutorial-3-${DRONE_TAG##srs20??-tutorial3-}.pdf
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
include ../pandoc-opts.mk
|
||||
|
||||
SOURCES_2 = tutorial-2.md setup.md maatma.md what.md netfilter.md anssi.md vitrine.md nameserver.md
|
||||
SOURCES_2 = tutorial-2.md setup.md maatma.md what.md netfilter.md anssi.md vitrine.md nameserver.md nameserver-anssi.md nameserver-troubleshooting.md
|
||||
SOURCES_ANSIBLE = tutorial.md ansible.md deploiement-svc.md rendu.md
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Durcir les configurations de base
|
|||
---------------------------------
|
||||
|
||||
Le pare-feu va vous aider à être moins susceptible d'attirer l'attention en
|
||||
présentant des scans épurés, et en n'exposant exclusivement que les ports
|
||||
présentant des scans épurés, et en exposant exclusivement que les ports
|
||||
nécessaires, aux bonnes personnes. Mais vous allez sans doute devoir présenter
|
||||
un certain nombre de services à Internet. Il convient donc de sécuriser au
|
||||
mieux ces services.
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
|
|
@ -0,0 +1,44 @@
|
|||
Recommandations
|
||||
---------------
|
||||
|
||||
Nouvelle page de publicité, l'ANSSI publie également un guide de bonnes
|
||||
pratiques sur l'aquisition et l'exploitation de noms de domaines :
|
||||
<https://www.ssi.gouv.fr/uploads/2014/05/guide_dns_fr_anssi_1.3.pdf>
|
||||
|
||||
{width=20%}
|
||||
|
||||
Vous n'avez pas de recommandations à tirer de ce guide, mais dans le cas où
|
||||
vous auriez la responsabilité d'un domaine, c'est un guide à prendre en compte.
|
||||
|
||||
|
||||
### DNSSEC (bonus)
|
||||
|
||||
Le DNS est un vieux protocole, particulièrement important sur Internet. Il
|
||||
souffre malheureusement de son âge, en particulier de part le manque de
|
||||
plusieurs mécanismes de sécurité. Citons notamment le fait que les paquets
|
||||
transitent en clair, souvent via UDP, sans mécanisme d'authentification ni de
|
||||
signature.
|
||||
|
||||
Pour améliorer la situation, DNSSEC est une extension du protocole DNS qui
|
||||
permet de publier des signatures pour chaque enregistrement.
|
||||
|
||||
Pour ce faire, et toujours parce que l'on se trouve dans le cadre d'une
|
||||
structure arborescente, les clefs publiques permettant de valider les
|
||||
enregistrements d'un domaine en particulier, sont à publier dans la zone
|
||||
parente. C'est pourquoi, vous disposez sur Maatma, d'une interface vous
|
||||
permettant d'indiquer vos clefs publiques.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
Vous devriez sécuriser les réponses envoyées par votre serveur DNS en
|
||||
configurant DNSSEC.
|
||||
|
||||
De nombreux articles sont disponibles sur Internet pour vous permettre de
|
||||
configurer DNSSEC en fonction du serveur faisant autorité que vous aurez
|
||||
choisi.
|
||||
|
||||
Prenez garde, les signatures doivent être regénérées régulièrement. Ne
|
||||
choisissez pas une méthode ancestrale qui n'utiliserait pas les fonctionnalités
|
||||
de signature autonome du programme !
|
||||
|
||||
:::::
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
Dépannage DNS
|
||||
-------------
|
||||
|
||||
### Problèmes de cache
|
||||
|
||||
Le DNS, comme on a pu le voir, est une structure hiérarchisée et fortement
|
||||
sollicitée.
|
||||
|
||||
Afin d'éviter un engorgement excessif de certains serveurs (`.com` par
|
||||
exemple !) et de mieux répartir la charge entre les acteurs, un système de
|
||||
cache permet de garder en mémoire les derniers enregistrements consultés, dans
|
||||
la limite de leur durée de vie, annoncé par le champ TTL de chaque
|
||||
enregistrement.
|
||||
|
||||
<div lang="en-US">
|
||||
```
|
||||
42sh$ dig adlin.nemunai.re A
|
||||
[...]
|
||||
;; ANSWER SECTION:
|
||||
adlin.nemunai.re. 78942 IN A 82.64.31.248
|
||||
[...]
|
||||
```
|
||||
</div>
|
||||
|
||||
`78942` c'est le nombre de secondes durant lequel l'enregistrement `A` pour le
|
||||
domaine `adlin.nemunai.re.` sera retourné par le résolveur, sans effectuer tout
|
||||
le cheminement de résolution.
|
||||
|
||||
C'est vous dans le fichier de zone qui pouvez indiquer la durée que vous
|
||||
souhaitez utiliser : une durée faible vous permettra de plus facilement tester
|
||||
différents paramètres ou de changer régulièrement les enregistrements (pour
|
||||
tester c'est plutôt pratique), mais cela peut engendre une sollicitation
|
||||
excessive de votre serveur. À l'inverse, un cache long permet de se prémunir
|
||||
contre des problèmes de disponibilité, et tend à réduire les sollicitation du
|
||||
serveur faisant autorité.
|
||||
|
||||
Tous les résolveurs étant indépendant, il n'existe pas de moyen[^PURGE_CACHE] pour vider le
|
||||
cache d'un résolveur que vous ne contrôlez pas, afin qu'il n'ait plus en cache
|
||||
une donnée potentiellement erronée. Il faut attendre la fin du TTL sur chaque
|
||||
résolveur.
|
||||
|
||||
[^PURGE_CACHE]: Ce n'est pas exactement vrai, Cloudflare et Google ont des
|
||||
formulaires pour forcer le vidage du cache de leurs résolveurs publics :
|
||||
<https://1.1.1.1/purge-cache/> et
|
||||
<https://developers.google.com/speed/public-dns/cache>.
|
||||
|
||||
Ce problème cause parfois de gros problème, ce fût notamment le [cas pour Slack
|
||||
en
|
||||
2021](https://slack.engineering/what-happened-during-slacks-dnssec-rollout/).
|
||||
|
||||
Si vous êtes confronté à un problème avec votre zone, commencez par regarder le
|
||||
TTL de l'enregistrement retourné par votre résolveur local.
|
||||
|
||||
|
||||
### Outils
|
||||
|
||||
Lorsque vous allez établir votre délégation, vous pourriez utiliser l'outil
|
||||
[Zonemaster](https://www.zonemaster.fr/fr/) pour diagnostiquer d'éventuels
|
||||
problèmes avec vos enregistrements, les *GLUE records*, ...
|
||||
|
||||
Pour diagnostiquer des problèmes liés à DNSSEC, vous pouvez utiliser :
|
||||
|
||||
- [DNSViz](https://dnsviz.net/)
|
||||
- [DNSSEC Analyzer](https://dnssec-analyzer.verisignlabs.com/)
|
||||
|
||||
|
||||
#### happyDomain
|
||||
|
||||
Enfin, pour gérer votre fichier de zone, vous pourriez vouloir passer par une
|
||||
interface web. Vous pouvez regarder du côté
|
||||
d'[happyDomain](https://www.happydomain.org/), que vous pouvez installer à côté
|
||||
de votre serveur DNS faisant autorité (exemple pour
|
||||
[knot](https://help.happydomain.org/fr/deploy/knot/)).
|
||||
|
|
@ -12,7 +12,7 @@ xxxx.wordpress.com fourni par le gestionnaire du service.
|
|||
Nous allons maintenant gérer notre propre domaine.\
|
||||
|
||||
La deuxième solution proposée par Maatma est une délégation de nom de domaine.
|
||||
Alors que jusque-là, c'était les serveurs DNS de Maatma qui répondaient aux
|
||||
Alors que jusque-là, c'étaient les serveurs DNS de Maatma qui répondaient aux
|
||||
requêtes DNS, avec la délégation, ce sera à vous, dans votre VM, de répondre
|
||||
aux requêtes venues tout droit d'Internet.
|
||||
|
||||
|
|
@ -149,9 +149,41 @@ Ce sont les administrateurs de la zone `wikipedia.org.` qui ont indiqué à
|
|||
`org.` quels étaient leurs serveurs de noms. Et ils ont également donné des
|
||||
*GLUE records*, pour permettre à la magie d'opérer.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
À vous maintenant de créer votre zone, en envoyant sur Maatma, le nom de
|
||||
domaine votre serveur de noms, ainsi que le *GLUE record* qui lui correspond.
|
||||
|
||||
:::::
|
||||
|
||||
::::: {.warning}
|
||||
|
||||
Rappelez-vous que vous ne disposez que d'une plage IPv6 publique. La
|
||||
connectivité IPv4 est fournie par Maatma, lorsque les protocoles
|
||||
permettent de router les paquets entrant.
|
||||
|
||||
Bien qu'il serait théoriquement possible de le faire pour le DNS,
|
||||
**Maatma n'assure pas la résolution de vos noms de domaines**.
|
||||
|
||||
Lorsque vous définissez votre *GLUE record*, vous ne devez indiquer
|
||||
que l'adresse IPv6 de votre serveur faisant autorité. **N'indiquez pas
|
||||
l'IPv4 de Maatma pour le sous-domaine dédié au serveur de noms.**
|
||||
|
||||
Même si vous êtes dans un réseau entièrement IPv4, le résolveur de ce
|
||||
réseau va *généralement*[^NOLOCALIPv6] transmettre les requêtes à un
|
||||
résolveur qui aura une connectivité IPv6.
|
||||
|
||||
[^NOLOCALIPv6]: Un résolveur pour une entité peut faire le choix de
|
||||
résoudre lui-même les noms de domaines, et de ne pas être relié en
|
||||
IPv6. Néanmoins vous ne serez pas confronté à ce cas de figure sur
|
||||
les réseaux que vous utiliserez (EPITA, FAI français, ...). Si
|
||||
vous l'êtes tout de même, changez l'adresse de votre résolveur
|
||||
pour utiliser un résolveur public tel que celui de
|
||||
[FDN](https://www.fdn.fr/actions/dns/) ou
|
||||
[d'autres](https://en.wikipedia.org/wiki/Public_recursive_name_server).
|
||||
|
||||
:::::
|
||||
|
||||
|
||||
## À propos de Maatma et du portail IPv4
|
||||
|
||||
|
|
@ -160,25 +192,9 @@ routable sur Internet. Mais aujourd'hui encore, de nombreuses
|
|||
installations ne disposent pas de ce protocole de communication et ne
|
||||
peuvent accéder aux machines connectées en IPv4 seulement.
|
||||
|
||||
Pour palier cela, Maatma met à votre disposition une IPv4 mutualisée
|
||||
Pour pallier cela, Maatma met à votre disposition une IPv4 mutualisée
|
||||
entre tous les SRS. Un service écoute sur la machine au bout de cette
|
||||
IP, afin de distribuer le trafic entre vous, selon la demande du
|
||||
client. Tous les protocoles ne permettent pas d'identifier le domaine
|
||||
de destination, donc ce sont les protocoles HTTP et HTTPS qui sont
|
||||
transmis sur vos IPv6.
|
||||
|
||||
|
||||
|
||||
## DNSSEC (bonus)
|
||||
|
||||
En bonus, vous devriez sécuriser les réponses envoyées par votre serveur DNS.
|
||||
|
||||
Pour ce faire, et toujours parce que l'on se trouve dans le cadre d'une
|
||||
structure arborescente, les clefs publiques permettant de valider les
|
||||
enregistrements d'un domaine en particulier, sont publiées dans la zone
|
||||
parente. C'est pourquoi, vous disposez sur Maatma, d'une interface vous
|
||||
permettant d'indiquer vos clefs publiques.
|
||||
|
||||
De nombreux articles sont disponibles sur Internet pour vous permettre de
|
||||
configurer DNSSEC en fonction du serveur autoritaire que vous aurez choisi. À
|
||||
vous de jouer !
|
||||
|
|
|
|||
|
|
@ -7,16 +7,16 @@ un minimum de sécurités pour anticiper les menaces potentielles.
|
|||
### Identifier les menaces
|
||||
|
||||
Il y a deux grandes catégories de menaces lorsque l'on rend visible
|
||||
une machine sur Internet :
|
||||
une machine sur Internet :
|
||||
|
||||
- les scans automatiques ;
|
||||
- les individus/organisations.
|
||||
|
||||
Dès qu'une machine est accessible sur Internet, celle-ci est scannée
|
||||
par des robots de nombreuses entités qui récoltent des informations ou
|
||||
même tente des attaques classiques.
|
||||
même tentent des attaques classiques.
|
||||
|
||||
Voici des exemples :
|
||||
Voici des exemples :
|
||||
|
||||
- [Shodan](https://www.safetydetectives.com/blog/what-is-shodan-and-how-to-use-it-most-effectively/),
|
||||
- [Wordpress/phpMyAdmin et autres scanner vulnérabilités](https://cirt.net/Nikto2),
|
||||
|
|
@ -47,10 +47,10 @@ en place un pare-feu.
|
|||
|
||||
Sur un serveur Linux fraîchement installé, aucune règle de filtrage n'est
|
||||
appliquée. (Sur certaines version Desktop de distribution, un pare-feu est
|
||||
configuré pour n'accepte aucune connexion entrante).
|
||||
configuré pour n'accepter aucune connexion entrante).
|
||||
|
||||
Avant de commencer notre filtrage, regardons quels programmes sont en écoute
|
||||
sur notre machine :
|
||||
sur notre machine :
|
||||
|
||||
```
|
||||
ss --listen --numeric --processes --tcp
|
||||
|
|
@ -71,16 +71,15 @@ les autres daemons pour faire en sorte qu'ils ne soient pas lancés inutilement
|
|||
|
||||
### Atténuer les menaces
|
||||
|
||||
Avec `ss`, nous sommes en mesure de savoir précisément de quels ports nous
|
||||
avons besoin d'ouvrir sur notre machine. Cependant, nous faisons face à 2
|
||||
problèmes :
|
||||
Avec `ss`, nous sommes en mesure de savoir précisément quels ports nous avons
|
||||
besoin d'ouvrir sur notre machine. Cependant, nous faisons face à 2 problèmes :
|
||||
|
||||
- on ne peut pas limiter facilement avec `bind(2)` les IP auxquelles on
|
||||
voudrait autoriser l'accès du service (par exemple : tout Internet n'a pas
|
||||
voudrait autoriser l'accès du service (par exemple : tout Internet n'a pas
|
||||
besoin d'accèder à notre serveur SSH, on en a seulement besoin pour
|
||||
administrer notre serveur, on arrivera sans doute d'une IP connue d'avance),
|
||||
- et si d'autres programmes se mettent à écouter sur des ports pendant le cycle
|
||||
de vie d'un autre programme ?
|
||||
de vie d'un autre programme ?
|
||||
|
||||
Pour réduire les risques, nous devons mettre en place des règles de pare-feu.
|
||||
|
||||
|
|
@ -106,11 +105,11 @@ Le pare-feu du noyau Linux est `netfilter`. On interagit avec lui avec des
|
|||
appels systèmes, et de nombreux logiciels permettent de gérer plus ou moins
|
||||
facilement les règles.
|
||||
|
||||
Il y a 2 implémentations de référence :
|
||||
Il y a 2 implémentations de référence :
|
||||
|
||||
- `iptables` : utilisé depuis 1998, il est aujourd'hui présent et utilisé par
|
||||
- `iptables` : utilisé depuis 1998, il est aujourd'hui présent et utilisé par
|
||||
la majorité des administrateurs système.
|
||||
- `nftables` : stable depuis 2021, il tend à remplacer `iptables`, aux
|
||||
- `nftables` : stable depuis 2021, il tend à remplacer `iptables`, aux
|
||||
fonctionnalités vieillissantes (séparation IPv4/IPv6, vitesse de traitement,
|
||||
...).
|
||||
|
||||
|
|
@ -120,13 +119,13 @@ utiliser `nftables`, mais libre à vous d'utiliser l'implémentation de votre
|
|||
choix.
|
||||
|
||||
Pour afficher la liste des règles actuellement appliquées, on utilise les
|
||||
commandes suivantes :
|
||||
commandes suivantes :
|
||||
|
||||
```
|
||||
nft list ruleset
|
||||
```
|
||||
|
||||
ou avec `iptables` :
|
||||
ou avec `iptables` :
|
||||
|
||||
```
|
||||
iptables -t $TABLE --list
|
||||
|
|
@ -140,19 +139,19 @@ y a aussi `nat`, `mangle`, ...\
|
|||
|
||||
::::: {.warning}
|
||||
|
||||
Faites attention lorsque vous changer les règles de pare-feu à distance, car
|
||||
Faites attention lorsque vous changez les règles de pare-feu à distance, car
|
||||
votre connexion passe par ce pare-feu. Si vous bloquez toutes les connexions
|
||||
entrantes avant d'autoriser votre connexion SSH, vous vous retrouverez à la porte.
|
||||
|
||||
Dans le contexte de ce TP, vous avez accès à la console dans votre hyperviseur
|
||||
pour remédier à la situation, mais parfois vous pouviez n'avoir comme solution
|
||||
pour remédier à la situation, mais parfois vous pourriez n'avoir comme solution
|
||||
que le redémarrage (les règles ne sont pas persistantes), voire le déplacement
|
||||
dans le datacenter, si vos règles sont chargées automatiquement au démarrage !
|
||||
dans le datacenter, si vos règles sont chargées automatiquement au démarrage !
|
||||
|
||||
:::::
|
||||
|
||||
Avant d'interdire toutes les connexions entrantes, nous allons donc autoriser
|
||||
notre connexion SSH ! On commence par créer une table :
|
||||
notre connexion SSH ! On commence par créer une table :
|
||||
|
||||
```
|
||||
nft add table inet <mytable>
|
||||
|
|
@ -163,7 +162,7 @@ trafic IPv4 et IPv6 à la fois ([voir les autres types de table
|
|||
supportés](https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families)).
|
||||
|
||||
Au sein de notre table, nous allons maintenant créer une chaîne de règle. C'est
|
||||
ici que l'on va indiquer à quel `hook` du noyau on souhaite s'accrocher :
|
||||
ici que l'on va indiquer à quel `hook` du noyau on souhaite s'accrocher :
|
||||
plutôt les paquets entrant, sortant, traversant, ...
|
||||
|
||||
```
|
||||
|
|
@ -177,7 +176,7 @@ Cela permet d'indiquer au noyau à quel niveau on souhaite appliquer ces
|
|||
règles.
|
||||
|
||||
Ajoutons justement notre première règle pour autoriser les connections
|
||||
SSH :
|
||||
SSH :
|
||||
|
||||
```
|
||||
nft add rule inet <mytable> <mychain> tcp dport 22 accept
|
||||
|
|
@ -185,7 +184,7 @@ nft add rule inet <mytable> <mychain> tcp dport 22 accept
|
|||
|
||||
Au sein d'un chaîne, sauf rares exceptions, les règles sont évaluées
|
||||
séquentiellement et la première décision qui valide les conditions est retenue.
|
||||
Dans notre exemple ci-dessus, la décision est d'accepter (`accept`) le paquet :
|
||||
Dans notre exemple ci-dessus, la décision est d'accepter (`accept`) le paquet :
|
||||
si aucune règle n'existe avant, validant aussi les conditions, cette règle sera
|
||||
la dernière d'un paquet TCP à destination du port 22, il sera ensuite délivré à
|
||||
l'espace utilisateur.
|
||||
|
|
@ -199,13 +198,13 @@ paquet](https://wiki.nftables.org/wiki-nftables/index.php/Quick_reference-nftabl
|
|||
Enfin, changeons la politique par défaut pour les paquets entrant pour lesquels
|
||||
aucune décision n'a été prise, qui est d'accepter tous les paquets, vers la
|
||||
politique `drop`, qui envoie vers un trou noir les paquets qui n'auront pas
|
||||
étéacceptés dans la chaîne.
|
||||
été acceptés dans la chaîne.
|
||||
|
||||
```
|
||||
nft add chain inet <mytable> <mychain> '{ policy drop; }'
|
||||
```
|
||||
|
||||
Eh voilà ! vous êtes en sécurité.
|
||||
Eh voilà ! vous êtes en sécurité.
|
||||
|
||||
::::: {.exercice}
|
||||
|
||||
|
|
|
|||
|
|
@ -42,11 +42,11 @@ Dans le cas d'un site web, nous retrouvons un guide de l'ANSSI dédié :\
|
|||
|
||||
::::: {.exercice}
|
||||
|
||||
Le guide est une nouvelle fois fort passionant, mais nous nous concentrerons
|
||||
Le guide est une nouvelle fois fort passionnant, mais nous nous concentrerons
|
||||
aujourd'hui exclusivement sur la recommandation R1 : *Mettre en œuvre TLS à
|
||||
l'état de l'art*.
|
||||
|
||||
Entre autres, il s'agit déjà de disposer d'un certificat valide pour votre
|
||||
Entre autre, il s'agit déjà de disposer d'un certificat valide pour votre
|
||||
vitrine.
|
||||
|
||||
:::::
|
||||
|
|
@ -69,16 +69,16 @@ l'interface de Maatma pour pouvoir l'utiliser.
|
|||
|
||||
:::::
|
||||
|
||||
Let's Encrypt est une entitée qui génère de manière automatisée et gratuitement
|
||||
Let's Encrypt est une entité qui génère de manière automatisée et gratuitement
|
||||
des certificats TLS, dans le but de sécuriser l'accès aux services d'un domaine
|
||||
(que ce soit pour utiliser HTTPS, SMTPS, FTPS, ...).
|
||||
|
||||
Leur service repose sur un test de propriété du domain, qui peut être réalisé
|
||||
de différentes manière (`http-01`, `dns-01`, ...). Une fois le test de
|
||||
Leur service repose sur un test de propriété du domaine, qui peut être réalisé
|
||||
de différentes manières (`http-01`, `dns-01`, ...). Une fois le test de
|
||||
propriété validé, il est possible de faire émettre un certificat pour une durée
|
||||
de 90 jours, pour le domaine validé.
|
||||
|
||||
Ce court délais permet d'éviter d'avoir trop de révocations, mais cela implique
|
||||
Ce court délai permet d'éviter d'avoir trop de révocations, mais cela implique
|
||||
aux administrateurs d'automatiser la gestion des certificats (par exemple via
|
||||
une tâche *cron* qui va régulièrement venir renouveler les certificats et
|
||||
relancer les services qui les utilisent).
|
||||
|
|
@ -88,7 +88,7 @@ ACME](https://www.rfc-editor.org/rfc/rfc8555) : citons notamment
|
|||
[`certbot`](https://eff-certbot.readthedocs.io/en/stable/index.html)
|
||||
(implémentation officielle, mais dont l'installation et l'usage tendent à se
|
||||
complexifier même dans le cas des installations les plus simples), ou
|
||||
[`dehydrated`](https://github.com/dehydrated-io/dehydrated) (qui fourni un
|
||||
[`dehydrated`](https://github.com/dehydrated-io/dehydrated) (qui fournit un
|
||||
script dont le seul but est de générer un certificat sur une installation
|
||||
existante, avec moins de dépendances à l'installation). Mais de nombreux autres
|
||||
projets sont tout aussi viables pour utiliser le protocole ACME.
|
||||
|
|
|
|||
Reference in New Issue