Après avoir déployé le cluster QUIC, le certificat https initialement demandé a expiré, j'ai donc essayé de réinstaller / mettre à jour le certificat.
Let's Encrypt est un projet gratuit qui émet automatiquement des certificats https.
Certbot est l'outil client officiel de génération de certificats recommandé par Let's Encrypt
Étant donné que mon cluster quic copie directement le certificat d'origine dans un répertoire personnalisé, certbot n'a pas été installé, installez donc d'abord certbot.
Installez Certbot
Installez d'abord snapd, en fonction de votre propre système Linux (le mien est Red Hat Enterprise Linux 8), sélectionnez le didacticiel d'installation snapd correspondant
Installez snapd
$ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
$ sudo dnf upgrade
$ sudo yum install snapd
Créer un lien souple
$ sudo systemctl enable --now snapd.socket
$ sudo ln -s /var/lib/snapd/snap /snap
Installez Certbot
## 更新snap到最新的版本
sudo snap install core
sudo snap refresh core
## 去除其余Certbot操作系统包 确保安装后使用certbot命令使用的是snap
sudo apt-get remove certbot
sudo dnf remove certbot
sudo yum remove certbot
sudo snap install --classic certbot
#创建软链接
sudo ln -s /snap/bin/certbot /usr/bin/certbot
renouveler le certificat
Comme j'ai stocké l'ancien certificat sur la machine, mon idée initiale était de mettre à jour directement l'ancien certificat. D'abord, certbot certificatesvérifiez les informations de certificat du serveur actuel,
mais le résultat ne m'a pas renvoyé les informations de certificat actuelles. Je suppose que cela peut être dû au fait que j'ai uniquement migré le fichier pem nécessaire pour configurer nginx lorsque j'ai migré le certificat, et que le chemin de stockage est également différent du chemin par défaut lorsque l'ancien cluster a installé le certificat.
J'ai empaqueté tous les fichiers sous le chemin du certificat d'origine / etc / letsencrypt et je les ai téléchargés sur le même chemin sur la machine Nginx du nouveau cluster, puis j'ai utilisé le certbot certificatescertificat de vérification pour voir l'ancien certificat.
Ensuite, utilisez la certbot renewcommande pour mettre à jour le certificat .
Problèmes rencontrés:
lors du renouvellement du certificat, il y aura une erreur signalée, indiquant que la
connexion échoue lors de l' accès à xxx / .well-known / acme-challenge / xxx pour vérifier la propriété du nom de domaine.
Étant donné que le cluster nginx déployé par aws lie le nom de domaine à l'équilibreur de charge, l'équilibreur de charge n'a écouté que le port 443 de quic au début. Après avoir ajouté l'écoute sur le port 80, il n'indique plus qu'il ne peut pas se connecter et renvoie un 404 code d'erreur.
Le jugement était dû à l'inaccessibilité du chemin ci-dessus. Après de nombreuses tentatives, le chemin n'a pas pu être trouvé. Enfin, j'ai pensé que cette demande visait à vérifier la propriété du nom de domaine, mais j'ai lié le nom de domaine à l'équilibreur de charge , pas le serveur qui a mis à jour le certificat., Liez le nom de domaine à l'adresse IP du serveur et exécutez à nouveau certbot renew, la mise à jour est réussie
Étant donné que le chemin du nouveau certificat est différent du précédent, le chemin du certificat dans le fichier de configuration nginx doit être modifié comme suit:
ssl_certificate /etc/letsencrypt/live/you.domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/you.domain.com/privkey.pem;
Après la mise à jour du certificat, liez le nom de domaine à l'équilibreur de charge
Limite de fréquence des demandes de certificat Letencrypt
https://letsencrypt.org/zh-cn/docs/rate-limits/
Il y a une limite de 5 échecs de vérification par compte, par heure et par domaine. La limite est plus élevée dans l'environnement de test (60 échecs de vérification sont autorisés par heure)
La limite de jusqu'à 5 certificats en double par nom de domaine enregistré par semaine
Ainsi, lorsque j'utilise à plusieurs reprises la commande certbot renouveler, il se peut qu'une invite m'indique que la limite supérieure a été atteinte. Veuillez réessayer après un certain temps.
En fin de compte, je viens de migrer et de mettre à jour le certificat, mais il y aura toujours des problèmes avec la mise à jour ultérieure de cette opération (le nom de domaine doit être lié à l'ip du serveur correspondant), ce qui est encore plus gênant.
Le suivi continuera à étudier, s'il y a une bonne solution, le blog sera mis à jour. Si vous avez traité des problèmes similaires, vous pouvez le partager
参考资料:
Installation de snap sur Red Hat Enterprise Linux (RHEL) Aucune des réponses
ci-dessus sur CentOS / RHEL 8