Let's Encrypt

Support Debian
#1

Hello, y’en a qui ont tenté l’aventure “Let’s Encrypt” ici ?!

Je lis deux, trois articles, histoire de me lancer :

Je clone le depôt git …
=> Paramètre du fichier de config.ini, ainsi :

# We use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096
email = webmaster@stephane-huc.net
domains = stephane-huc.net, www.stephane-huc.net
authenticator = webroot
# This is the webroot directory of your domain in which
# letsencrypt will write a hash in /.well-known/acme-challenge directory.
webroot-path = /srv/www/mydomain/www

Je modifie mon fichier serveur nginx, pour rajouter :

 location '/.well-known/acme-challenge' {
        allow all;
        default_type "text/plain";
        root /srv/www/mydomain/www;
        try_files $uri /$1;
}

(non, petit malin, la racine de mes fichiers ne se trouvent pas sur /srv/www/mydomain/www … ce répertoire n’existe pas du tout - c’est simplement pour faire comprendre !
Néanmoins, dans ces deux fichiers de configuration, sur mon serveur, cela pointe bien au bon endroit.)

Et, j’ai pourtant le droit à l’erreur suivante :

Hors, http://stephane-huc.net/.well-known/ est accessible depuis “dehors” !

Je me suis amusé à mettre les droits root:root sur le répertoire .well-known/, à tester avec les droits de l’utilisateur lié à nginx, pour le domaine en question … ça ne change rien !
J’ai même dû enlever les règles interdisant l’accès aux fichiers dits cachés, commençant par ‘.’, parce que malgré la règle “allow all” dans la déclaration location relative au répertoire .well-know, j’avais le droit à l’erreur 404.
Je viens même d’essayer avec un chmod 777 sur ledit répertoire …

Ça m’énerve passablement, parce que j’y ai passé toute mon après-midi, pour un truc qui devrait rouler en quelques minutes, pffff …
:frowning:

#2

Salut !

Oui ça tourne depuis un moment chez moi :slight_smile: (je suis la personne ayant rédigé l’article consacré à Let’s Encrypt sur noobunbox.net)

Peux-tu stp coller la configuration entière du domaine concerné ?

j’ai essayé d’aller sur ton site et j’ai une erreur

Ce site est inaccessible

stephane-huc.net a mis trop de temps à répondre.
ERR_CONNECTION_TIMED_OUT
#3

Bizarre, car je suis intéressé par ce domaine et je viens de tester la connexion sur le site de Stephane et ça fonctionne

#4

Je suis entrain de générer une clé DHParam à 4096, qui me ralenti méchamment le bouzin !

Après mettre ma config entière - moi qui suis un tantinet parano sur les bords - sachant qu’elle est un poil complexe …

Entre-temps, j’ai découvert qu’il ne fallait pas l’utilisateur nginx mais bien root sur les répertoires ./well-known/acme-challenge/

Entre temps, j’ai découvert que mes règles iptables bloquaient la discussion avec les serveurs du projets Let’sEncrypt - et, là, j’aimerais bien comprendre aussi pourquoi !
C’est vraiment bizarre, d’autant qu’en sortie le port 80 est autorisé, ainsi qu’en entrée, et absolument les connexions relatives et établies …

Et, quand j’ai eu fait pété toutes mes protections et autres paramétrages, le script m’a statué d’un congratulation!

Grrr…

#5

Chez moi les répertoires n’ont pas les droits root et ca fonctionne :slight_smile:

1 J'aime
#6

Ahhh, je préfère largement ça !

Ma clé DH Param vient de terminer - elle aura mis près de 4 heures pour être générée ! pfff

“Stay tuned!” Je vérifie ma config, et on va tester la conn https !

#7

j’ai toujours un timeout :confused:

#8

le premier lien ne fonctionne pas, essai le second ou ajoute un slash à la fin.
http://stephane-huc.net/.well-known/

#9

Je teste directement sur le domaine http://stephane-huc.net et impossible d’acceder à la page

#10

Ouais, j’ai apparemment un problème, j’ai un tas de petit malin qui m’envoie des gets dans la goule !

Ouais, non la fatigue n’aide pas à y voir clair … tsss …
Ça, c’est plutôt, si je ne me trompe pas, apt-mirror ! tsss
Va falloir que je trouve le moyen de limiter son action, car il me plombe les ressources CPU. grrrr

#11

Pour info, je sais pas si tu t’en es finalement sorti, mais je suis passé à Let’s Encrypt récemment et j’avais donné ma marche à suivre (qui me semble plus simple que la tienne ?) à Ricardo, ici. Si ça peut aider ;-).

#12

Merci seb-ksl.
Je regarderais ça dès que possible. Vraiment pas assez dormi, moi. tsss

Mais, bon le serveur tourne ! :stuck_out_tongue:
Avec redirection vers HTTPS active.

Booo : https://www.ssllabs.com/ssltest/analyze.html?d=stephane-huc.net

#13

Assessment failed: Unable to connect to the server

Que ça me lourde !
Pourquoi il n’arrive pas à se connecter ssllabs ?
Qu’est-ce qui peut l’en empêcher ?

#14

Tu as bien configuré tes ciphers?

https://mozilla.github.io/server-side-tls/ssl-config-generator/

#15

Je te remercie.

J’ai modifié pour faire “joujou” en mode Intermediate ou Modern.
En mode intermediate, je me connecte avec FF (v45.0) ou Opera (v12.16) sous Linux
En mode modern, seul FF se connecte !

Bien, déjà, ça semble bon.
Bascule de HTTP vers HTTPS : ok!

J’ai enfin eu le droit à un zoli “A+” !!! :smiley:

1 J'aime
#16

Voilà ce que j’utilise chez moi :

(Ça permet d’avoir un maximum de navigateurs et OS supportés sans trop perdre en sécurité)

ssl_certificate /etc/letsencrypt/live/noobunbox.net/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/noobunbox.net/privkey.pem;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers “ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA”;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve secp384r1;

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_buffer_size 8k;
ssl_session_tickets off;
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/noobunbox.net/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Par contre commente la ligne suivante si tu n’utilises pas HTTPS sur tout tes sous-domaines. Ca risque de les rendre inaccessibles sinon

add_header Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”;

#17

Là, sur ce coup, je te remercie … en effet, mon blog est revenu ! _[quote=“Novakin, post:16, topic:68791”]
resolver_timeout 5s;
[/quote]

Ahhh, le coup du symbole ‘_’ et non pas ‘-’ … je comprends mieux pourquoi il ne reconnaissait pas cette option - bon, perso, j’ai mis à 3s
Et, resolver sur 127.0.0.1.

Je n’ai pas paramétré cette option, l’ayant vu dans un fichier de config, mais comme je ne me suis pas encore renseignée dessus … pas fait

#18

En gros ça te permet de mieux sécuriser l’échange de clé ECDH.

Sur ton test https://www.ssllabs.com/ssltest/analyze.html?d=stephane-huc.net on voit que tu utilises
une clef ECDH secp256r1

#19

Ok,

Tiens, par contre, mon serveur nginx me sort ça :

$ sudo nginx -t
nginx: [warn] "ssl_stapling" ignored, host not found in OCSP responder "ocsp.int-x1.letsencrypt.org/"

Étonnant ? non ?

#20

Ca doit venir de la

Change l’IP du resolver, si tu ne veux pas utiliser les DNS de google tu peux utiliser OpenNIC ou FDN