La beta fermée est quasiment terminée, le beta ouverte est prévue début décembre.

Question peut-être bête mais je ne suis pas super calé niveau certificats.

Les certificats Let's Encrypt, qui sont reconnus par tout les navigateurs, le sont aussi implicitement par les autres applications ? Je pense au tutoriel mail (postfix + dovecot etc..), on peu utiliser le certificat let's encrypt ?

J'en utilise un et je n'ai pas de probleme de mail particulier.
Ils sont toujours accepté partout en boite de reception (yahoo, gmail, ect..) sauf comme d'hab pour moi ils sont en spam chez hotmail.

Rien de bien différent par rapport à avant donc.
Ca se trouve j'ai plein de probleme et j'en sais rien

@coom & @spider1163: il n'y a aucune différence entre un certificat utilisé pour un serveur de mail et un serveur web (en tout cas, dans le cas de LE, les flags sont bons pour les deux usages), donc let's encrypt peut être utilisé pour sécuriser des échanges mails sans soucis.

FAQ wrote:Will Let’s Encrypt issue certificates for anything other than SSL/TLS for websites?

Let’s Encrypt certificates will be standard Domain Validation certificates, so you can use them for any server that uses a domain name, like web servers.

Donc implicitement ils disent que leurs certificats fonctionnent pour d'autres usages que du web, par exemple du mail, messagerie xmpp...etc

Can I use certificates from Let’s Encrypt for code signing or email encryption?

No. Email encryption and code signing require a different type of certificate than Let’s Encrypt will be issuing.

La FAQ dit autre chose, leurs certificats ne peuvent pas être utilisés pour signer du code (avec une infrastructure PKI par exemple), et pour chiffrer du mail (pas la communication/transfert des données mais l'email en lui même).

Le client ACME de Let's encrypt ne support pas officiellement d'autres usages que du web (et encore, le support est très limité niveau serveur web).

@coom: Donc techniquement, aucun soucis d'utiliser LE avec dovecot et postfix, tu n'auras juste pas les gestion automatique des certificats à partir de leur client ACME, c'est la seule différence.

Source : https://community.letsencrypt.org/t/use-on-non-web-servers/425

Salut Hardware,

Merci pour ce retour d'information, je vais tenter d'utiliser les certificats Let's Encrypt pour mes serveurs mails, afin d'eviter d'utiliser des certificats auto-signés. Seulement, je ne comprends pas très bien cette partie de ton post :

Hardware wrote: @coom: Donc techniquement, aucun soucis d'utiliser LE avec dovecot et postfix, tu n'auras juste pas les gestion automatique des certificats à partir de leur client ACME, c'est la seule différence.

Le client ACME sert à envoyer la requete pour le nom de domaine, a récuperer le certificat, et (eventuellement, selon le type de serveur Web) a modifier le fichier de conf du serveur web pour implémenter les certificats.

Si je comprends bien, tu m'expliques que je devrais manuellement inclure les certificats dans les fichiers de conf des differents services qui l'utilisent (IMAP, POP, etc ..) ? Si c'est ça, je me doutais que ce serait le cas. Utilisant nginx, je dois déja plus ou moins me débrouiller a la main.

Question bête, en utilisant des lien symboliques, on peut automatiser tout ca, non ?

Ex, dans ma conf dovecot, j'explique que le certificat est dans /etc/ssl/moncertif.cer, qui est en fait un lien symbolique pointant vers /etc/letsencrypt/mondomain.tld/certif.cer, apriori, le simple fait de mettre à jour le certificat Web suffirait ?

Désolé si mes questions peuvent sembler farfelues. Je m'y connais plutot bien en Administration, mais je suis une quiche en Certificats.

coom wrote:Si je comprends bien, tu m'expliques que je devrais manuellement inclure les certificats dans les fichiers de conf des differents services qui l'utilisent (IMAP, POP, etc ..) ?

Tout à fait.

Une fois que ton service est configuré avec un certificat Let's Encrypt, lorsque le certificat arrivera à expiration, il suffira juste de relancer le client ACME pour renouveler le certificat, donc aucune modification sera à faire niveau configuration.

Ca marche. Merci beaucoup d'avoir pris le temps de m'expliquer Hardware !

Je vais m'ateler à ca.

Pour info, la bêta publique de Let's Encrypt est ouverte !

coom wrote:Et plutot bonne nouvelle, depuis la beta ouverte, même si on sait que les certificats "wildards" ne sont pas acceptés (et ont apriori, pas vocation a l'être par Let's Encrypt), on peu désormais obtenir un certificat pour autre chose que domain.tld et www.domain.tld !

J'ai fait l'essai avec domain.tld, www.domain.tld, mail.domain.tld et torrent.domain.tld : ca fonctionne tip top.

http://img15.hostingpics.net/pics/6842952015120323h3205.png

8o)

Cool ton thème rutorrent, c'est quoi ?

@Jede :
Tu devrais ajouté ce lien à ton tutoriel, c'est bien expliqué pour générer un certificat :
https://letsencrypt.readthedocs.org/en/latest/using.html#installation

coom wrote:Et plutot bonne nouvelle, depuis la beta ouverte, même si on sait que les certificats "wildards" ne sont pas acceptés (et ont apriori, pas vocation a l'être par Let's Encrypt), on peu désormais obtenir un certificat pour autre chose que domain.tld et www.domain.tld !

J'ai fait l'essai avec domain.tld, www.domain.tld, mail.domain.tld et torrent.domain.tld : ca fonctionne tip top.

http://img15.hostingpics.net/pics/6842952015120323h3205.png

8o)

Et du coup, si j'ai déja enregistré un domaine durant la beta fermée, je fais comment pour obtenir un certif pour chacun de mes sous domaine ? Je relance l'instal ?

winz: tu relances le même process que pour la beta fermée, mais sans spécifier le serveur. Au moment ou il te demande les domaines, tu les specifie tous en les séparant par un espace.

Tu peu aussi faire ca avec un "one-liner" :

/tmp/letsencrypt/letsencrypt-auto auth -d domain.tld -d www.domain.tld -d torrent.domain.tld -d mail.domain.tld -d pop.domain.tld -d imap.domain.tld

etc etc..

xataz: C'est le thème Agent46.

coom wrote:winz: tu relances le même process que pour la beta fermée, mais sans spécifier le serveur. Au moment ou il te demande les domaines, tu les specifie tous en les séparant par un espace.

Tu peu aussi faire ca avec un "one-liner" :

/tmp/letsencrypt/letsencrypt-auto auth -d domain.tld -d www.domain.tld -d torrent.domain.tld -d mail.domain.tld -d pop.domain.tld -d imap.domain.tld

etc etc..

xataz: C'est le thème Agent46.

J'arrive pas à trouver à quoi l'argument "auth" corresponds

xataz: A la base le client sert à traiter avec les serveurs de Let's Encrypt afin de recuperer le certificat, et il configure au passage ton serveur web. Comme le support de nginx est tjs en beta (visiblement pas super stable aux dernieres news), tu peux utiliser "certonly" pour obtenir le certificat mais sans modifier la conf de ton serveur web.

Le mode "certonly" est aussi connu sous le nom "auth".

Source: letsencrypt-auto --help

root@linux:/tmp/letsencrypt# ./letsencrypt-auto --help
Updating letsencrypt and virtual environment dependencies.......
Running with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt --help

  letsencrypt [SUBCOMMAND] [options] [-d domain] [-d domain] ...

The Let's Encrypt agent can obtain and install HTTPS/TLS/SSL certificates.  By
default, it will attempt to use a webserver both for obtaining and installing
the cert. Major SUBCOMMANDS are:

  (default) run        Obtain & install a cert in your current webserver
  certonly             Obtain cert, but do not install it (aka "auth")

Perso j'ai fait ça

./letsencrypt-auto --help
./letsencrypt-auto certonly

bon il reste à faire quelques configurations https://www.ssllabs.com/ssltest/analyze.html?d=mondedie.fr&s=92.222.170.105

Petit tuto pour avoir un A+

Il faut se connecter en root, pour les opérations suivantes.

Il faut stopper nginx avant tout

service nginx stop

Toujours mettre à jour le serveur avant :

aptitude update && aptitude upgrade

mkdir /etc/nginx/ssl
openssl openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

# vim /etc/nginx/ssl/ciphers.conf

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_dhparam /etc/nginx/ssl/dhparam.pem;
ssl_session_cache shared:SSL:10m;
ssl_ecdh_curve secp384r1;
ssl_session_tickets off;

add_header Strict-Transport-Security "max-age=31536000";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;

note : le max age de Strict-Transport-Security correspond à 1an.

Ensuite il faut inclure le fichier ciphers.conf dans http {}

# vim /etc/nginx/nginx.conf

http {
    include /etc/nginx/ssl/ciphers.conf
}

Installation de letsencrypt

cd /tmp
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Après cette étape il faut générer le certificat via let's encrypt, avec une clée RSA de 4096bits

./letsencrypt-auto --help all
./letsencrypt-auto certonly --rsa-key-size 4096

Il faudra ajouter une adresse mail, accepter la licence, et ajouter les sous domaines espacer d'un espace.

Pour finir il faudra ajouter 2 lignes dans chacun de vos vhosts.

# vim /etc/nginx/sites-enbled/monsite.fr.conf

server {
    ssl_certificate /etc/letsencrypt/live/monsite.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/monsite.fr/privkey.pem;
}

Pour finaliser il ne faut pas oublier de redémarrer nginx

service nginx start

Quitte à avoir une configuration homogène, et pour éviter un léger surcoût CPU, mettre ssl_ecdh_curve à secp384r1 est plus que suffisant. Il est aussi bon de de savoir que par défaut, letsencrypt génère des clés RSA 2048 bits, il est donc possible d'utiliser une taille de 4096 par exemple, il suffira de préciser (c'est le petit plus pour les paranoïaques et ceux qui veulent gonfler leur note sur ssllabs).

Je suis du même avis que Wonderfall, mettre plutôt un ECC à 384 bits au lieu de 521, surtout pour des questions de compatibilité avec certains navigateurs :

ssl_ecdh_curve secp384r1;

Pour la suite de chiffrement je te conseil :

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"

ça équivaut à "EECDH+AES" mais sans ECDHE-ECDSA, inutile vu que ta clé publique est de type RSA.

Tout est expliqué ici : https://blog.imirhil.fr/2015/09/02/cryptcheck-verifiez-implementations-tls.html

Peut être aussi activer TLSv1 et v1.1 pour des raisons de compatibilité, mais bon les navigateurs récents supportent tous TLSv1.2, à voir.

Pour HSTS, vaut mieux partir sur la directive que tu as modifié :

add_header Strict-Transport-Security "max-age=31536000";

includeSubdomains pose soucis vu que plusieurs sous-domaines n'ont pas encore de certificats valides et la directive preload est inutile vu que mondedie.fr n'est pas présent dans les listes HSTS préchargées des navigateurs.

Mais sinon c'est good !

Et bim !
Prefix handling Not valid for "www.mondedie.fr" CONFUSING

Je confirme une belle erreur sur https://www.mondedie.fr
une redirection 301 ?

Bonjour à tous,
J'ai pris chez OVH un VPS, installé Prestashop par OVH.
Tout marche bien visiblement. Or je n'arrive pas a lancer Let's encrypt
Je me connecte en root et j'essaie de recuperer let's encrypt mais rien ne se passe.
Quelqu'un aurait il une idée ?
Mon niveau de compétence est franchement pas terrible, oui je sais ...

mirtouf wrote:Et bim !
Prefix handling Not valid for "www.mondedie.fr" CONFUSING

Je confirme une belle erreur sur https://www.mondedie.fr
une redirection 301 ?

c'est réglé.

malartic wrote:Bonjour à tous,
J'ai pris chez OVH un VPS, installé Prestashop par OVH.
Tout marche bien visiblement. Or je n'arrive pas a lancer Let's encrypt
Je me connecte en root et j'essaie de recuperer let's encrypt mais rien ne se passe.
Quelqu'un aurait il une idée ?
Mon niveau de compétence est franchement pas terrible, oui je sais ...

Copie/colle ton message d'erreur ici

Pour le faire en une commande (pratique pour des scripts d'auto génération, pour mettre à jour le cert) :

./letsencrypt-auto certonly --agree-tos -m contact@domain.tld -d mail.domain.tld -d domain.tld -d www.domain.tld

Merci Magicalex,
Le message d'erreur est le suivant :
bash : git : commande introuvable

malartic wrote:Merci Magicalex,
Le message d'erreur est le suivant :
bash : git : commande introuvable

apt-get install git

xataz wrote:

malartic wrote:Merci Magicalex,
Le message d'erreur est le suivant :
bash : git : commande introuvable

apt-get install git

A présent :
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
E: Impossible de trouver le paquet git

avec apt-get install git-core c'est pareil

Alors je vous l'avez pas dit que j'étais pas doué ?
Si mes posts floodent votre forums, je le comprends pas de soucis, surtout vu leur niveau.
Alors je m'arreterai là

Tente de faire :

apt-get update && apt-get upgrade && apt-get install git-core

xataz wrote:Tente de faire :

apt-get update && apt-get upgrade && apt-get install git-core

ça à l'air de fonctionner, je poursuis

J'ai réussi à avancer, grace à vous,
Tout se passe bien jusqu'à la fin et j'obtiens ceci :

Failed authorization procedure. domain.example.tld (tls-sni-01)
the server couldn't connect to the client for the DV Server failure at resolver

malartic wrote:J'ai réussi à avancer, grace à vous,
Tout se passe bien jusqu'à la fin et j'obtiens ceci :

Failed authorization procedure. domain.example.tld (tls-sni-01)
the server couldn't connect to the client for the DV Server failure at resolver

Peux tu préciser la commande que tu exécutes ?

Peux tu préciser la commande que tu exécutes ?

oui bien sur, j'ai procédé ainsi :
cd /tmp
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --agree-dev-preview --server https://acme-v01.api.letsencrypt.org/directory auth

ensuite je rentre mon email, mon domaine
puis j'obtiens le message suivant :

Failed authorization procedure. domain.example.tld (tls-sni-01)
the server couldn't connect to the client for the DV Server failure at resolver
Merci

Le fonctionnement à un peu changé en passant à la beta public:

Arrête nginx (ou autre serveur web) :

service nginx stop

Puis lance letsencrypt :

./letsencrypt-auto certonly

Les certificats ce trouvent ensuite dans /etc/letsencrypt/live


Relance ensuite nginx :

service nginx start

Merci Xataz,
Visiblement ça a fonctionné avec ton aide précieuse.

the certificate was successfully created and placed in /etc/nginx/live/example.com/

A présent je trouve sur le net des infos différentes je ne voudrais pas essayer n'importe quoi et tout planter.
J'ai eu pour l'instant des reponses comme : permission non accordé ou commande introuvable

Diesel wrote:bonsoir a tous

j'ai remarquer divers tutoriel sur le web qui regroupe des scripts .sh pour un renouvellement du ou des certificats apres 60 jours d'utilisation

notament celui ci :ici et celui la



une âme charitable suggérez ce bonus ?

Cordialement

A l'heure actuelle, il suffit "simplement" de relancer le processus et, par la suite, la procédure pourrait changer. Un script est-il vraiment nécessaire ?

Diesel wrote:

Solinvictus wrote:

Diesel wrote:bonsoir a tous

j'ai remarquer divers tutoriel sur le web qui regroupe des scripts .sh pour un renouvellement du ou des certificats apres 60 jours d'utilisation

notament celui ci :ici et celui la



une âme charitable suggérez ce bonus ?

Cordialement

A l'heure actuelle, il suffit "simplement" de relancer le processus et, par la suite, la procédure pourrait changer. Un script est-il vraiment nécessaire ?

Pour les tete en l'aire qui ne regarde pas specialement la date de fin de leur certificat je suppose que oui

Oui, sur ce point, je te rejoins