L'article suivant a été publié récemment.
Firefox bloque la politique car la plus grande autorité de certification de Chine "WoSign" a falsifié la date d'émission du certificat http://gigazine.net/news/20160928-wosign-firefox-block/
WoSign était pratique car il peut émettre des certificats SSL gratuitement pendant plusieurs années, mais il s'agissait d'une épidémie de falsification, ce qui était un problème.
Quand je cherchais un endroit pour émettre un certificat SSL gratuit au début de l'année dernière, je l'ai choisi car il n'y avait qu'un endroit remarquable comme WoSign, mais quand j'ai enquêté à nouveau, Let's Encrypt était 4 de cette année. Il était en train de passer de la version bêta au service officiel en mai.
Leaving Beta, New Sponsors https://letsencrypt.org/2016/04/12/leaving-beta-new-sponsors.html
Bon timing (rires)
C'est pourquoi j'ai décidé de renoncer à la falsification et aux services suspects.
La méthode d'introduction a été automatisée pour renverser la sagesse conventionnelle. Jusqu'à présent, je recevais des certificats SSL payés pour les entreprises, mais j'ai été surpris de constater qu'aucune procédure n'était prise pour acquise à l'époque.
--Avoir des droits de domaine --Un serveur WEB accessible dans ce domaine est en cours d'exécution
Puisqu'il n'y a que ces deux conditions, je les ai déjà remplies. Ou plutôt, il semble peu probable que vous souhaitiez un certificat SSL même si vous n'avez pas cette condition.
L'obtention d'un certificat est effectuée avec un outil appelé certbot. L'outil est sur github, donc on a l'impression de le tirer avec git et de l'utiliser.
cd /usr/local
git clone https://github.com/certbot/certbot
cd certbot/
Étant donné que le serveur introduit cette fois-ci était lié au référentiel Vault de CentOS 6.2, il était nécessaire d'activer temporairement la base et les mises à jour dans les étapes suivantes.
vi /etc/yum.repos.d/CentOS-Base.repo
Exécutez ensuite la commande suivante.
./certbot-auto
L'installation yum commencera, alors appuyez sur "y" pour continuer. Après un certain temps, la création du certificat a commencé de manière interactive avec un écran bleu, mais je n'avais pas le nom de domaine que je voulais dans les options, alors je l'ai annulée et terminée.
Ensuite, obtenez le certificat avec la commande suivante.
./certbot-auto certonly --webroot \
-w /var/www/hogehoge -d www.example.com \
-m [email protected] \
--agree-tos
certonly est une option qui ne nécessite que l'obtention d'un certificat. --webroot est une option pour mettre automatiquement un fichier d'authentification à la racine du document. À côté de -w se trouve le PATH de la racine du document publié dans le domaine. À côté de -d se trouve le nom de domaine pour lequel vous souhaitez obtenir un certificat. À côté de -m se trouve l'adresse e-mail de la personne responsable. C'est pour recevoir le contact quand quelque chose se passe. --agree-tos est une option indiquant que vous acceptez les conditions d'utilisation.
J'ai maintenant un certificat, mais j'obtiens l'avertissement suivant lors de l'exécution:
/root/.local/share/letsencrypt/lib/python2.6/site-packages/cryptography/__init__.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of cryptography will drop support for Python 2.6
Lorsque j'ai cherché sur Google, de nombreuses personnes ont rencontré des problèmes de version de Python. Il y avait plusieurs personnes qui étaient passées et celles qui prenaient des mesures avec SCL.
~~ J'ai aussi essayé de mettre 2.7 dans SCL, mais cela n'a pas fonctionné. ~~ Si vous regardez dans le PATH suivant, qui est entré lorsque certbot est installé ...
ll /root/.local/share/letsencrypt/lib/python2.6/
Total 344
lrwxrwxrwx 1 root root 32 29 septembre 13:53 2016 UserDict.py -> /usr/lib64/python2.6/UserDict.py
-rw-r--r--1 racine racine 10062 29 septembre 13:53 2016 UserDict.pyc
lrwxrwxrwx 1 racine racine 31 septembre 29 13:53 2016 _abcoll.py -> /usr/lib64/python2.6/_abcoll.py
-rw-r--r--1 racine racine 24165 29 septembre 13:53 2016 _abcoll.pyc
lrwxrwxrwx 1 root root 27 septembre 29 13:53 2016 abc.py -> /usr/lib64/python2.6/abc.py
-rw-r--r--1 racine racine 6357 29 septembre 13:53 2016 abc.pyc
lrwxrwxrwx 1 root root 30 septembre 29 13:53 2016 codecs.py -> /usr/lib64/python2.6/codecs.py
-rw-r--r--1 racine racine 39165 29 septembre 13:53 2016 codecs.pyc
lrwxrwxrwx 1 root root 27 septembre 29 13:53 2016 config -> /usr/lib64/python2.6/config
lrwxrwxrwx 1 root root 32 29 septembre 13:53 2016 copy_reg.py -> /usr/lib64/python2.6/copy_reg.py
Ce qui suit est omis
Un lien symbolique était directement attaché à Python 2.6 comme ceci. Donc, peu importe combien vous démarrez bash qui peut utiliser 2.7, il semble que vous obtiendrez un avertissement car 2.7 n'est pas utilisé et 2.6 Python est utilisé de force. ~~
~~ J'ai créé le certificat lui-même, donc je vais continuer, mais un jour il peut cesser de fonctionner complètement. ~~
Avec ce qui précède, l'avertissement de 2.6 n'a pas été affiché et 2.7 a été utilisé. Dans cet état, 2,7 caches ont été créés ci-dessous. /root/.local/share/letsencrypt/lib/python2.7
Cependant, si vous exécutez la commande certbot-auto sans scl enable python27 bash après cela, elle sera à nouveau remplacée par le cache 2.6, alors soyez prudent.
rm -rf /root/.local/share/letsencrypt
wget https://centos6.iuscommunity.org/ius-release.rpm
rpm -ivh ius-release.rpm
yum -y install python27 python27-devel python27-pip python27-setuptools python27-virtualenv
Après avoir terminé l'installation ci-dessus, je me suis reconnecté à la console et j'ai exécuté certbot-auto, et il a trouvé python2.7 et l'a utilisé sans autorisation. Python2.7 est également enregistré dans le cache. Avec cette méthode, je suis content car je ne fais pas l'erreur d'oublier accidentellement l'activation de scl et d'obtenir un cache 2.6 et d'obtenir un avertissement.
Écrivez ce qui suit dans les paramètres de serveur correspondants dans le fichier de configuration apache.
SSLCertificateFile /etc/letsencrypt/live/www.example.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.example.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.example.com/chain.pem
Ensuite, rechargez Apache et vous avez terminé.
service httpd reload
Let's Encrypt a une date d'expiration de seulement 90 jours. Par conséquent, il est difficile pour les humains de traiter à chaque fois, et cela semble être oublié.
Alors, mettez les paramètres dans crontab afin qu'il puisse être mis à jour avec une seule commande.
Ajouté le 15/11/2016 Ajoutez "source / opt / rh / python27 / enable;" au début de la commande
Ajouté le 2017/02/17 Dans le cas d'une méthode d'installation de python2.7 utilisant le référentiel ius, il n'est pas nécessaire d'ajouter "source / opt / rh / python27 / enable;".
crontab -u root -e
00 03 01 * * source /opt/rh/python27/enable;/usr/local/certbot/certbot-auto renew --force-renew && /sbin/service httpd reload
Ce qui précède est une commande pour renouveler de force le certificat à 3 h 00 le premier jour de chaque mois. Je ne peux pas dire tous les 90 jours dans crontab, donc je le fais tous les mois. Let's Encrypt a une limite supérieure sur la fréquence de mise à jour, mais il semble qu'il n'y ait pas de problème si c'est une fois par mois.
Cette fois, j'ai résumé les mesures prises face à une situation d'urgence dans laquelle le certificat SSL a dû être changé pour une autre organisation en raison d'une faute de la part de l'autorité de certification. ~~ C'est un peu regrettable que le problème de la version Python persiste, mais je suis content d'avoir pu le résoudre pour le moment. ~~ Je ne trouve aucun autre service comme Let's Encrypt, donc je crains un peu qu'il ne s'agisse que d'un seul, mais j'espère juste que le service continuera pour toujours.
Recommended Posts