Ce thread est la suite de [Troll] Let's Encrypt Tome IV
La limite est enfin passée et je vais pouvoir tenter de recertifier les deux hostnames de mon second serveur.
Votre aide précieuse serait franchement la bienvenue afin de ne pas encore terminer dans le ravin.
Côté technique :
- Chaque hostname possède son vhost apache2.
- Entre Internet et le serveur se trouve un frontend qui redirige les flux via tunnel SSH (lors du renouvellement en https, c'est le certificat autosigné du frontend qui est émis)
Donc au programme :
- certifier les deux hostnames
- automatiser le renouvellement des dit hostnames
J'éditerai le thread au fur et a mesure pour plus de clarté et signaler l'état d'avancement.
# heuuu
Posté par NeoX . Évalué à 4.
c'est peut-etre ca qui t'emmerde.
moi j'ai du rediriger le flux 443 de l'IP publique directement vers le https du apache
pour que le premier certificat soit correctement emis.
j'imagine qu'ensuite ca va etre pareil lors du renouvellement.
ou alors il faut que tu suives le mode d'emploi let's encrypt et haproxy…
en gros faire faire les certificats, non pas par le apache final, mais par la machine intermediaire,
c'est elle qui recoit les flux publiques, c'est elle qui fait le HTTPS,
ensuite c'est un flux, en clair ou signé dans ton tunnel mais independant du https publié avec letsencrypt
[^] # Re: heuuu
Posté par EauFroide . Évalué à 0. Dernière modification le 14 février 2017 à 16:45.
Tu veux dire dans le NAT? Si oui alors c'est impossible à automatiser (le NAT de cette BOX doit être configuré manuellement, elle peut créer automatiquement des entrées mais pas modifier (ni supprimer semble-t-il))
C'est se que je fais avec prestashop : c'est le frontend qui gère le renouvellement du certificat et quand un visiteur d'internet tente de joindre le service le frontend sert d’intermédiaire (et le certificat et son renouvellement son donc géré par le frontend).
Le problème c'est que pour les deux noms de domaine que je tente de certifier, c'est afin que les clients puissent joindre directement (sans intermédiaire) le second serveur depuis internet en utilisant le port 8443 (car 443 déjà occupé). Mais Let's Encrypt pour le challenge n'accepte que 80 et 443.
Un exemple (publique) est le tracker piwik suivant : https://o2.0rion.netlib.re:8443/services/bigbrother.js mon service de cloud suit cette même logique (mais j'ai pas envie de poster son URL ^ ^ ), et le joindre directement permet d'éviter de saturer le frontend.
Notons que j'avais déjà réussi à certifier les deux hostnames via serveur2 (en passant à travers le frontend et les tunnels), mais je n'ai pas réussi a renouveller, ni a re-certifier mes certificats après avoir ré-installé let's encrypt.
Mon problème du précédent thread indique, je pense, qu'il faut que j'arrive a renouveller en utilisant un challenge en http (80) évitant ainsi que le challenge râle a propos du certificat du frontend :)
PS: merci d'apporter ton aide NeoX, c'est une des plus précieuses de cette communauté :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
# Staging
Posté par aiolos . Évalué à 4.
Avant toute chose, pour ne pas te faire bloquer de nouveau, pense à tester tes configs et demandes de certificat sur l'environnement de test plutôt que la prod:
https://letsencrypt.org/docs/staging-environment/
[^] # Re: Staging
Posté par EauFroide . Évalué à 0.
Merci pour le liens, je vais passer par ça oui :) (je n'ai pas encore ré-essayé depuis le ban', Let's Encrypt a réussi a me démotiver).
J'en ai aussi profité pour parler a karchnu de l'ajout dans la liste publique bidule pour que le blocage de mon nom de domaine n’entraîne plus celui des autres utilisateurs de netlib.re :)
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.