[TUTO OBSOLÈTE] Certificat TLS/SSL - Let's Encrypt "Wildcard"

Herbs · le 2 novembre 2018

Bonsoir messieurs,

Je viens de passer "un peu" de temps à lire ce topic, et à mettre en place les solutions proposées par InfoYann et PPJP.

Tout semble OK chez moi, alors un grand merci à tous les contributeurs et en particulier aux 2 cités plus haut 😉 !!!!

unPixel · le 2 novembre 2018

De rien 😉

TabasKo · le 4 novembre 2018

(Salut les gars)

Purée ! moi qui voulais mettre en place en quelques heures mon certificat SSL ... je suis à deux doigts de lâcher l'affaire !

Comme j'ai un tas de NDD chez OVH, j'ai décidé d'en prendre 1 et de configurer un sous domaine (du genre nas.1ndd.com).
Jusque là, ok.

Par contre pour se procurer un certificat, c'est tout de suite plus opaque pour moi.
J'ai l'impression que l'autorité qui délivre le certificat doit (et c'est normal) s'assurer que je suis le propriétaire du domaine/sous-domaine indiqué.
Dès lors, je vois pas comment rendre possible cette opération sans avoir un serveur http ouvert sur le port 80 du NAS (chose que je ne souhaite pas faire).

C'est d'ailleurs explicitement demandé sur le NAS :

J'imagine qu'ouvrir le port 80 sur ma box en port-fowarding sur le NAS ne servirai à rien (puisqu'il n'y a à ma connaissance aucun service sur le port du nas)

Et si j'ouvre le port 80 sur la box, le message d'erreur devient

Un gros truc m'échappe ?

ps: je voudrai pas polluer vos échanges si c'est préférable que j'ouvre un nouveau thread dites le moi.

TabasKo · le 6 novembre 2018

Le 03/10/2018 à 12:41, PiwiLAbruti a dit :

Il vaut mieux limiter la surface d'exposition en utilisant uniquement les adresses nécessaires plutôt qu'un pays entier :

outbound1.letsencrypt.org 66.133.109.36

outbound2.letsencrypt.org 64.78.149.164

Le port 80 suffit n'est ce pas ? le 443 n'est pas utile.

C'est bien en TCP seulement qu'on l'autorise ?

https://snag.gy/vpW5lu.jpg

unPixel · le 6 novembre 2018

Oui, TCP et port 80 uniquement pour ces deux IP.

unPixel · le 18 décembre 2018

@PPJP,

Hello PPJP,

Je te tiens au courant puisque ça fait pas mal de temps que l'eau à coulé sous les ponts.

Le script fonctionne parfaitement pour la génération du script comme la dernière fois. Le seul soucis qui persiste, c'est le redémarrage de certains paquets qui ne se fait pas. Ils sont arrêtés dans le centre de paquets donc je suppose que le script arrive à leurs donner l'ordre de se relancer mais eux ne doivent pas y arriver.

J'ai fait un petit coup de :

synoservicecfg --list

Certains paquets n'apparaissent pas comme Office qui est concerné par les paquets qui ne redémarrent pas.

Ces prochains jours, je vais essayer de voir les logs sur le serveur pour chercher le pourquoi ça pêche dans le redémarrage de certains services.

Merci à toi en tout cas pour toute l'aide apportée avec ton script 😉

EDIT :

J'ai été lire le log "synoservice.log" et voilà le résultat :

Modifié le 18 décembre 2018 par Zeus

.Shad. · le 30 décembre 2018

Bonjour à tous,

Beaucoup d'infos dans ce sujet, j'ai essayé de trouver une réponse quant à un renouvellement automatique, je n'ai rien vu de clair.
Mon certificat SSL for free va-t-il se renouveler automatiquement (à la manière d'un certificat créé via DSM) à l'expiration des trois mois ou dois-je refaire la manipulation initiale ?

Thierry94 · le 30 décembre 2018

Bonjour,

Le certificat se renouvellera automatiquement au bout des 3 mois. Pour cela il suffit que le port 80 en TCP soit ouvert sur votre NAS, et votre routeur pendant la période de renouvellement.
Pour plus de sécurité il est possible de limiter l'ouverture du port 80 aux 2 adresses IP utilisées par Let's Encrypt.
Mais si vous ne voulez pas attendre le renouvellement automatique vous pouvez le déclencher manuellement directement sur DSM (ouvrir préalablement le port 80 !)

unPixel · le 30 décembre 2018

Il y a 8 heures, shadowking a dit :

Bonjour à tous,

Beaucoup d'infos dans ce sujet, j'ai essayé de trouver une réponse quant à un renouvellement automatique, je n'ai rien vu de clair.
Mon certificat SSL for free va-t-il se renouveler automatiquement (à la manière d'un certificat créé via DSM) à l'expiration des trois mois ou dois-je refaire la manipulation initiale ?

Ça dépend, tu as créé comment ton certificat SSL ?!

Création via DSM directement - renouvellement automatique tous les trois mois en ouvrant le port 80 sur les USA ou mieux sur les deux IP de Let's Encrypt.
Création via mon tutoriel, il faut que tu refasses ton certificat tous les trois mois et que tu l'importes en remplaçant l'ancien. Si tu t'es inscrit sur le site, tu seras prévenu par mail qu'il faut que tu renouvelles.
Si création via acme en ayant suivi la discussion "très" longue, tu n'as rien à faire, ça renouvelle tout seul un certificat wildcard.

Modifié le 30 décembre 2018 par Zeus

.Shad. · le 30 décembre 2018

Je parlais de la méthode du tutoriel oui, j'ai d'autres certificats non wildcard créés via DSM pour d'autres applications.
J'ai bien reçu un mail mais je voulais être certain que c'était la marche à suivre.
Du coup je testerai sûrement à l'avenir la troisième méthode, quand j'aurai pris le temps de tout lire.

Merci !

unPixel · le 30 décembre 2018

Pas encore définitif la troisième méthode parce que je rencontre encore un petit soucis sur le redémarrage auto de certains paquets...

Donc pour la partie tuto, c'est bien à toi de faire la demande de renouvellement depuis le site indiqué. Synology n'a pas encore intégré la possibilité de faire un certificat wildcard donc il n'y a pas le choix.

unPixel · le 10 février 2019

Bon, j'ai essayé de me pencher un peu plus sur ces soucis de paquets qui ne redémarre pas et autant dire que pour le moment, le soucis ne me parle pas.

Voici la liste exacte des paquets qui ne se relance pas à la demande :

Moments
Office
phpMyAdmin
Apache 2.2
Apache 2.4

J'ai donc tenté de lancer au départ Apache 2.2 via la commande :

/usr/syno/sbin/synoservicecfg --restart pkgctl-Apache2.2

La commande est bien passée mais rien n'a été fait. C'est normal puisque après réflexion, j'ai demandé le redémarrage d'un paquet non lancé. Je suppose donc que le système hôte n'a pu trouver l'ID du processus en question.

Je suis donc passé par la commande :

/usr/syno/sbin/synoservicecfg --start pkgctl-Apache2.2

Et là, j'ai vu un changement. Dans le centre de paquets, le démarrage s'est bien initialisé et était passer au statut "Démarrage en cours" sauf qu'il n'a jamais réussi à démarrer et il est resté dans cet état.

J'ai donc décidé de tenter le redémarrage du NAS pour voir si les services allaient se relancer via DSM. Je ne voulais pas les lancer manuellement depuis le centre de paquets car lors de mes précédents soucis du même ordre, je savais que ça fonctionnait.

Après redémarrage via la commande reboot en SSH, je suis allé dans le centre de paquets et les paquets cités plus haut n'étaient toujours pas démarrés. Logique me direz-vous puisqu'ils étaient déjà arrêtés avant le reboot. DSM en a donc certainement conclu qu'il ne fallait pas les redémarrer puisqu'il prend en compte l'état on/off des paquets avant une extinction.

J'ai donc lancé manuellement depuis le centre de paquets ces paquets et je suis aller voir au niveau des logs SSH et en particulier le fichier synoservice.log

En voici le résultat suite au lancement manuel des dits paquets via le centre de paquets.

https://framabin.org/p/?14d2eaf1f5e55544#KhZAWFZhA4YI+d+rPoaH6WJS4y9AGV1FbZuTjc5HjIU=

J'ai quand même cherché aussi au moment ou j'avais lancé le script pour voir ce qu'il s'était passé au niveau du redémarrage des paquets et voilà le résultat :

https://framabin.org/p/?98e0e9edee1d9262#Xq2sVwrDmBegoCJ0zkqvQxWlN1FyMKhEwMARfsMpyJg=

Bref, je patauge et je ne comprend pas pourquoi ils ne peuvent pas se relancer lorsqu'on leur demande...

Modifié le 13 février 2019 par Zeus

Jojo (BE) · le 10 février 2019

parce qu'ils sont têtus comme des bourriques :lol:

unPixel · le 10 février 2019

Au jour d'aujourd'hui, je ne recommande pas encore de passer par la méthode à laquelle je passe n'ayant pas encore résolu ce soucis alors si vous voulez un certificat wildcard, passez par un tiers recommandé par Let's Encrypt comme SSLFORFREE.

C'est d'ailleurs pour ça qu'en dehors du premier post parlant de SSLFORFREE, tout le reste n'est que brouillon et test.

Sans compter qu'on est limité dans les tests de génération de certificat et que ces derniers se renouvelle tous les trois mois d'eux même. Donc assez chiant pour faire des tests sur de courtes périodes.

En passant par un service tiers qui utilise l'API de Let's Encrypt comme le faire SSLFORFREE, ça se génère en deux minutes et on importe le nouveau certificat dans DSM sans soucis en quelques instants aussi. Et là, pas de soucis de redémarrage de paquets...

Mic13710 · le 10 février 2019

As-tu essayé le redémarrage proposé par Neilpang pour l'acme.sh ?

https://github.com/Neilpang/acme.sh/wiki/Synology-NAS-Guide

PACKAGECERTROOTDIR="/usr/local/etc/certificate"
FULLCERTDIR="$CERTROOTDIR/$CERTDIR"

# reload
/usr/syno/sbin/synoservicectl --reload nginx

# update and restart all installed packages
PEMFILES=$(find $PACKAGECERTROOTDIR -name cert.pem)
if [ ! -z "$PEMFILES" ]; then
	for DIR in $PEMFILES; do
              #active directory has it's own certificate so we do not update that package
              if [[ $DIR != *"/ActiveDirectoryServer/"* ]]; then
		rsync -avh "$FULLCERTDIR/" "$(dirname $DIR)/"
		/usr/syno/bin/synopkg restart $(echo $DIR | awk -F/ '{print $6}')
              fi
	done
fi

Einsteinium · le 10 février 2019

Bientôt 1 an... qu’attend synology pour l’implementation ?

unPixel · le 10 février 2019

@Mic13710

Oui j'ai essayé mais je pense avoir fait une erreur dans la modification du script car j'ai reçu un message d'erreur par mail sans précision de ce dernier.

Et comme j'y connais pas grand chose en bash, je n'arrive pas à me décoincer du soucis.

PPJP · le 11 février 2019

@Zeus

Bonsoir,
Désolé car j'ai loupé le message ou tu me citais.
Je ne suis pas très régulier sur ce forum et ai la mauvaise habitude de ne pas m'identifier car je n'ai pas à y écrire.

Concernant le script, les redémarrages demandés de paquets semblent se faire correctement.
Le redémarrage des paquets arrêtés ne doivent pas avoir été demandés.

Il est difficile de savoir quels sont les paquets arrêtés lors de la mise à jour du certificat.
Chez moi tous les paquets sont OK dont phpMyAdmin.

Pour test, je viens d'installer Apache 2.2, Apache 2.4 et Moments.
Résultat: Les 2 Apaches OK,(sans demande de redémarrage par le script) et Moments arrêté.
Donc pas cohérent avec ce qui est constaté chez toi.
Je crains que l'on soit devant un problème de dépendance.

@Mic13710

Le redémarrage proposé par Neilpang ne relancera les mêmes paquets que le script actuel.

@Zeus

A toute fin utile je joins une nouvelle version du script qui ne fait pas appel au CRON.
C'est une modif que j'avais faite après constat d'un risque de rater un renouvellement.
Le Nas était en arrêt pour dépoussiérage périodique (heureusement il était également lancé au boot).
Si l'on rate un créneau le suivant arrive après péremption du certificat.

Il est lancé journellement par une tache planifiée par:
Pour un renouvellement à 85 jours
bash /pathduscript/majcertificat.sh > /pathduscript/majcertificat.log 2>&1
Pour un renouvellement à X jours (X de 0 à 90)
bash /pathduscript/majcertificat.sh X > /pathduscript/majcertificat.log 2>&1

Si utilisation de pas oublier de supprimer a ligne de crontab correpondant à l'ancienne vesion

Le script oublié!!!

majcertificat.sh

unPixel · le 11 février 2019

Merci pour ton retour, je vais jeter un œil à ton script.

Citation

Il est difficile de savoir quels sont les paquets arrêtés lors de la mise à jour du certificat.

Pas forcément, suffit d'aller voir dans les logs ssh et on voit normalement ce qui a été fait par le système. Non ?

Citation

Il est difficile de savoir quels sont les paquets arrêtés lors de la mise à jour du certificat.
Chez moi tous les paquets sont OK dont phpMyAdmin.

Pour test, je viens d'installer Apache 2.2, Apache 2.4 et Moments.
Résultat: Les 2 Apaches OK,(sans demande de redémarrage par le script) et Moments arrêté.
Donc pas cohérent avec ce qui est constaté chez toi.
Je crains que l'on soit devant un problème de dépendance.

Merci pour les tests effectués de ton côté. C'est vrai que c'est assez chiant ce phénomène. Surtout pour Apache qui me bloque la connexion sur mon virtual host par exemple.

Et bien entendu phpMyAdmin qui me bloque aussi au niveau des sites.

Il faut vraiment que je réfléchisse à comment je peux arranger ce foutu soucis de redémarrage sur certains paquets.

Je pense que ce que je vais faire, c'est tout reprendre à 0.

Passer par SSLFORFREE pour obtenir un certificat et l'injecter dans DSM.
Surveiller les logs afin de voir les actions du système surtout sur la partie redémarrage de paquets
Refaire un certificat via acme sur mon NAS en essayant de régler le soucis.

EDIT :

Après un test rapide en réimportant l'ancien certificat d'origine Synology, supprimant le certificat Wildcard et le mettant par défaut sur tous mes services, voici le résultat dans les logs :

On peut voir qu'il ne redémarre aucun paquet à proprement parler en ce qu'il concerne les paquets qui posent soucis.

Je me demande si il ne faudrait pas dire au script de simplement redémarrer nginx et avahi et pourquoi pas nmbd. Après tout, c'est pas ces trois services qui gèrent tous les protocoles réseau sur le serveur ?

https://framabin.org/p/?2f5a4923d0dbc8cf#phSR6VJQlI5j5y1Jz2/3z/EipEo1rAxqIO+9FE1eB4s=

Modifié le 13 février 2019 par Zeus

PPJP · le 12 février 2019

Je viens de regarder le fichier synoservice.log et je n'ai pas tout compris.
On voit que Moments est arrêté (2 fois), et n'est jamais redémarré.
Le script ne demande ni l’arrêt ni le redémarrage de ce paquet!

J'ai rajouter en fin de script une commande de restart de Moments.
Cela fonctionne.C'est sale mais c'est une piste de recherche.

Donc pour moi
Déjà installé phpMyAdmin: a toujours été OK
Installé pour test Apache 2.2 a toujours été OK
Apache 2.4 a toujours été OK
Moments redémarre avec l'ajout de commande en fin de script

Pour info la partie de synoservice.log correspondante

https://framabin.org/p/?bebd694c53abf131#L+ZTx9qp//6sm6cB7h1fV+Ybf9ZLpinV7jBcrsTLzho=

PS: je viens de découvrir la modif de ton post

Je vais regarder, dans les prochaines soirées, ce que l'on peut obtenir de cette nouvelle piste qui semble intéressante.

Modifié le 14 février 2019 par PPJP

unPixel · le 12 février 2019

J'essaie d'apprendre pour scripté en bash mais pas facile parce que les 3/4 des sites proposent des scripts et n'expliquent pas les bases pour un débutant.

Sinon, j'ai modifier le script pour tenter le redémarrage uniquement de nginx, avahi et nmbd.

Tiens moi au courant de ton test, je pense que ça pourrait suffire mais je n'en suis pas sûr.

Tu pourrais stp me donner un exemple dans ton script pour ajouter par exemple la commande pour Moments.

#Redémarrage des packages
    echo -e "\nRedémarrage des packages"
    t0=$SECONDS
    echo "Redémarrage de nginx"
    /usr/syno/sbin/synoservicectl --reload nginx
    echo "Temps de redémarrage : $(($SECONDS - $t0))s"
    IFS=$'\n'
    for package in $(sort -u <<<"${paquets[*]}");do
        echo "Redémarrage de $package"
        t0=$SECONDS
        /usr/syno/bin/synopkg restart $package
        echo "Temps de redémarrage : $(($SECONDS - $t0))s"
    done
    unset IFS
    echo "Redémarrage de nginx"
    /usr/syno/sbin/synoservicectl --reload nginx
    echo "Temps de redémarrage : $(($SECONDS - $t0))s"

PPJP · le 12 février 2019

Bonsoir,

Je suis comme toi, je ne programme pas en Bash, que je le trouve imbuvable!

Ci-jointe une nouvelle version qui doit relancer Moments (elle fonctionne chez moi).

Tiens moi au courant du résultat. (paquets non relancés)

Je te joindrai dans qq temps une version pour relancer les Apache, mais je ne pourrai pas la tester car je n'ai jamais eu d’arrêts de ces paquets

majcertificat.sh

Einsteinium · le 12 février 2019

Les gas c’est invivable vos log ici... je vous recommande l’utilisation de https://pastebin.com/

unPixel · le 13 février 2019

Ok pour Pastebin 😉

@PPJP

Je viens d'essayer ton script et malheureusement le renouvellement se fait pas car il détecte qu'il est trop récent:

Demarrage du script (v02.00):  Wed Feb 13 15:13:05 CET 2019
Age du certificat : 1 jour(s)
1550067185
1549927802
Ecart : 139383s
Renouvellement du certificat non nécessaire

PPJP · le 13 février 2019

Bonsoir,

Je fais court pour ne pas m'attirer les foudres d'un modo (grand adepte des fessées!)

Le 11/02/2019 à 02:46, PPJP a dit :

Pour un renouvellement à 85 jours
bash /pathduscript/majcertificat.sh > /pathduscript/majcertificat.log 2>&1
Pour un renouvellement à X jours (X de 0 à 90)
bash /pathduscript/majcertificat.sh X > /pathduscript/majcertificat.log 2>&1

Lance avec le paramètre à 0

Connexion

[TUTO OBSOLÈTE] Certificat TLS/SSL - Let's Encrypt "Wildcard"

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

unPixel

unPixel

unPixel

Images postées

Rejoindre la conversation

Qui est en ligne 5 membres, 0 anonyme, 255 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante