CACert : certificat principal et WILDCARD, gratuits

fr
#1

Malgré le temps que j’ai mis à le rédiger, et les vérifications effectuées de mon côté, ce document peut comporter des erreurs.

Les liens et informations ne sont pas données pour rien. Prenez le temps de lire avant d’effectuer cette démarche. :slight_smile:

.
.
Bonjour tout le monde.

Suite à ce problème là, je rédige un processus fonctionnel pour la postérité. :slight_smile:
Et, il faut le dire, j’en suis très content. :slight_smile: Bon, comme j’utilise un peu de bidouille, il doit être perfectible.

J’ai eu du mal à effectué la tâche que j’ai réalisé, mais pour vous, à la fin de cette démarche, vous ne devriez plus avoir besoin d’ajouter d’exceptions de sécurité sur les navigateurs.

Je suis parti de cette page d’explication pour mettre un certificat sur mon serveur web.

J’avais déjà repéré CaCert, donc, je me suis dis, youpi j’y fonce.


**Une parenthèse ici : **

Avant de continuer, il faut savoir que c’est une communauté où il faut s’inscrire. Donc :

  • On s’enregistre sur leur site web.
  • On donne une adresse mail de son serveur domaine.tld qui est valide (de préférence admin@domaine.tld ou webmaster@domaine.tld)
  • On certifie notre nom de domaine avant de demander le certificat serveur.
    • Plus nous rencontrons les autres utilisateurs de CaCert, plus nous obtenons de points. A partir de 50 points (trois rencontres pour moi), nos certificats sont valables 2 ans et deviennent reconnus par les navigateurs (au moins firefox) !
  • On peut passer à la suite de la procédure.

Bon, gros dilemme. Sur la page officiel de Yunohost sur les certificat, je n’avais rien compris à cette portion là… Je suppose que certains d’entre-vous non plus. Je vous la mets quand même, ce sera utile pour la suite :

"Ces deux fichiers doivent être copiés sur le serveur, s’ils ne s’y trouvent pas déjà.

scp CERTIFICAT.crt admin@DOMAIN.TLD:ssl.crt
scp CLE.key admin@DOMAIN.TLD:ssl.key

Depuis Windows, scp est exploitable avec putty, en téléchargeant l’outil pscp

pscp -P 22 CERTIFICAT.crt admin@DOMAIN.TLD:ssl.crt
pscp -P 22 CLE.key admin@DOMAIN.TLD:ssl.key

Dès lors que les fichiers sont sur le serveur, le reste du travail se fera sur celui-ci. En ssh ou en local."

Youpi. Donc, si j’ai bien compris, je fait mon certificat puis je le télécharge. Reste à trouver comment faire.
A force de bidouilles et de recherches, je suis tombé au bout de quelques heures, en fouillant dans les méandres de l’Internet et du site de CaCert sur cette pépite.

Il existe aussi une alternative faisant intervenir un script dont je ne connais pas le détail, mais qui permet de prendre en compte les sous-domaines avec le domaine principal. Il suffit de remplacer mon petit 1 et petit 2 par la partie “Génération d’un certificat” du lien fournit ici.


Mon Anglais n’est pas terrible, mais je comprend le minimum :

  1. On génère la clef et on fait notre CSR (Il s’agit d’une demande de certificat sous forme de code reprenant les informations qu’on a glissé dans un questionnaire)
    PuTTY est votre allié, (en fait, chez moi c’est WinSCP sous windows qui se combien bien avec PuTTY)
    openssl req -nodes -newkey rsa:4096 -keyout my.key -out my.csr
    my.key et my.csr sont respectivement la clef publique de votre domaine et la demande de certificat. Vous pouvez remplacer “my” par votre propre mot, par exemple “demande” ou “clef”. J’ai donc pour l’exemple, demande.csr et clef.key afin de mieux m’y retrouver.

  2. A ce moment, voici le texte type à saisir :

    Country Name (2 letter code) [AU]: FR (pour la france)
    State or Province Name (full name) [Some-State]: votredépartement
    Locality Name (eg, city) []: votreville
    Organization Name (eg, company) [Internet Widgits Pty Ltd]: votrenom ou celui de votre association
    Organizational Unit Name (eg, section) []: votrenom
    Common Name (eg, YOUR name) []: votre domaine.tld
    .

  3. On peut relire le contenu de demande.csr en saisissant dans PuTTY. On n’oublie pas de copier le contenu :

     nano demande.csr 
    

.
4. Via son navigateur, on rentre ce qu’on vient de copier dans cette page en cochant la petite case du bas (je commente personnellement en expliquant pour quel serveur est cette demande) et on obtient son certificat ! VICTOIRE !
5. Encore une fois, PuTTY est votre allié. On colle le certificat avant de l’enregistrer.

nano certificat.crt

Et là c’est magique. Vous vous souvenez de cette phrase à laquelle je me retrouvais coincé au début ?

“Ces deux fichiers doivent être copiés sur le serveur, s’ils ne s’y trouvent pas déjà.”

Et bien c’est fait. clef.key et certificat.crt représentent respectivement les deux fichiers requis et nommés par Yunohost comme ssl.key et ssl.crt.

J’ai sauté la dernière étape de ma fameuse pépite et je suis revenu sur cette page d’explication de Yunohost en n’oubliant de remplacer ssl.crt et ssl.key par les noms que j’ai moi même donné (dans notre exemple, c’est clef.key et certificat.crt).

Le processus reprend donc à la ligne :

Tout d’abord, créez un dossier pour stocker les certificats obtenus.
sudo mkdir /etc/yunohost/certs/DOMAIN.TLD/ae_certs

Puis passe par l’option Cacert et termine par :
sudo service nginx reload

Avec cette étape, notre nom de domaine principal vient de recevoir son certificat.

Vous pouvez directement sauter aux dernières informations de fin de tutoriel.


Si vous avez des noms de sous-domaine. Ils ne sont pas certifiés d’une façon autre que par votre nom de domaine principal.
Les navigateurs ne les reconnaissent donc pas et invitent vos visiteurs à ajouter une exception si ils vous font confiance.

Nous allons donc faire une seconde demande de certification, mais cette fois pour les sous-domaines. C’est la certification wildcard qui coute 130€ chez certains…

Nous recommençons à l’étape 1 de ma pépite.

  1. On génère la clef et on fait notre CSR.
    PuTTY est votre allié,
    openssl req -nodes -newkey rsa:4096 -keyout masecondeclef.key -out subdomain_demand.csr

  2. A ce moment, voici le texte type à saisir ATTENTION, LA DERNIÈRE LIGNE CHANGE :

    Country Name (2 letter code) [AU]: FR (pour la france)
    State or Province Name (full name) [Some-State]: votredépartement
    Locality Name (eg, city) []: votreville
    Organization Name (eg, company) [Internet Widgits Pty Ltd]: votrenom ou celui de votre association
    Organizational Unit Name (eg, section) []: votrenom
    Common Name (eg, YOUR name) []: *.domaine.tld
    N’oubliez pas l’étoile devant de domaine.tld. C’est avec ce *.domaine.tld que l’on demande la certification pour tous les sous-domaines de votre serveur !
    .

  3. On peut relire le contenu de subdomain_demand.csr en saisissant dans PuTTY. On n’oublie pas de copier le contenu :

     nano subdomain_demande.csr 
    

.
4. Via son navigateur, on rentre ce qu’on vient de copier dans cette page en cochant la petite case du bas (je commente personnellement en expliquant pour qu’il s’agit d’une demande pour les sous-domaines, cela permet de s’y retrouver lorsque l’on retourne sur le site de CaCert) et on obtient son second certificat pour l’ensemble des sous-domaines !
.
5. Encore une fois, PuTTY est votre allié. On colle notre certificat avant de l’enregistrer.

nano subdomain_certificat.crt

masecondeclef.key et subdomain_certificat.crt représentent maintenant respectivement les deux fichiers requis et nommés par Yunohost comme ssl.key et ssl.crt.
.
6. Avant d’aller plus loin.
Il ne faut pas écraser le couple clef/certificat de votre domaine principal. Nous allons donc orienter les nouveaux certificats dans un dossier conçu spécialement pour eux : "subdomain"

sudo mkdir /etc/yunohost/certs/DOMAIN.TLD/subdomain

Voici le document officiel de Yunohost, transformé pour permettre de ne pas écraser les premiers fichiers créés.

Les certificats intermédiaires et root doivent être réunis avec le certificat obtenu pour créer une chaîne de certificats unifiés.

cat ae_certs/subdomain_certificat.crt ae_certs/intermediate_ca.pem ae_certs/ca.pem | sudo tee subdomain/crt.pem

La clé privée doit être, elle, convertie au format pem.

sudo openssl rsa -in ae_certs/masecondeclef.key -out subdomain/key.pem -outform PEM

Afin de s’assurer de la syntaxe des certificats, vérifiez le contenu des fichiers avant de continuer avec :

cd subdomain/
cat crt.pem key.pem

Enfin, sécurisez les fichiers de votre certificat.

sudo chown root:metronome crt.pem key.pem
sudo chmod 640 crt.pem key.pem

.
8. Il faut maintenant copier ces deux nouveaux éléments dans les dossiers sous-domaines respectifs :

sudo cp *.pem /etc/yunohost/certs/SUBDOMAIN.DOMAIN.TLD/

En remplaçant SUBDOMAIN.DOMAIN.TLD par le nom de sous domaine à certifier. A recommencer pour chaque sous domaine qui reçoit des visiteurs.
.
9. Vous pouvez terminer par :

sudo service nginx reload` 

Avec cette étape, chaque sous-domaine de votre serveur vient de recevoir son certificat.


Informations complémentaires :

  • ATTENTION : Une fois la création de certificat effectué, si de nouveaux sous-domaines sont créés, les nouveaux certificats automatiquement appliqués correspondent à des certificats autosignés. Il faut copier son duo certificat et clef (les deux fichiers *.pem) dans le dossier du nouveau sous-domaine pour qu’ils soient aussi reconnus par les navigateurs, puis :

      sudo service nginx reload` 
    
  • Si nous ne possédons pas les 50 points de certification chez CaCert, on ne pourra avoir de certificat de classe 3, et les navigateurs nous diront toujours de faire attention. Pensez donc à rencontrer des gens de la communauté Cacert avec un ou deux document-s d’identité AVANT DE FAIRE LA CERTIFICATION POUR LES SOUS DOMAINES car elle serait alors inutile. :slight_smile:

  • Chez GéoCerts, quoi que nous fassions, nous aurons toujours ce discours là mais cela ne pose pas de problème :

A valid Root CA Certificate could not be located, the certificate will likely display browser warnings.


J’espère que ce document vous aura été utile. :slight_smile:

4 Likes
Question ssl service
#2

Mise à Jour avec l’ajout :

  • en début de procédure d’un lien permettant de faire en UN SEUL script la demande pour le serveur principal et ses sous-domaines.
  • en fin de sujet des certificats racines de CAcert téléchargeable sur toutes les machines visiteurs afin d’éviter les erreurs potentielles.
#3

Merci pour ce guide très complet dont la lecture fut autant informative par son contenu que distrayante par son ton. Je n’ai pas encore essayé les certifcats CACert, le fait qu’ils ne soient pas inclus au sein des principaux navigateurs est un frein considérable à son adoption, mais ton document sera sans doute utile à d’autres, ou au moins à la posterité :wink:

Tu écris avoir eu des problèmes à comprendre la documentation de YunoHost, quels passages en particuliers t’ont posé problème ? Ton retour sera sans doute utile à d’autres utilisateurs :slight_smile:

1 Like
#4

Bonjour, merci pour ton retour. :slight_smile:

Lorsque je me suis intéressé aux certificats, je suis directement parti sur votre tutoriel d’ajout.

Or, dès le début du document, on nous parle de ceci :

Ajout d’un certificat signé par une autorité


Après création du certificat auprès de votre autorité 
d’enregistrement, vous devez être en possession d’une clé privée, le 
fichier key et d’un certificat public, le fichier crt.

Attention, le fichier key est très sensible, il est strictement personnel et doit être très bien sécurisé.

Ces deux fichiers doivent être copiés sur le serveur, s’ils ne s’y trouvent pas déjà.

scp CERTIFICAT.crt admin@DOMAIN.TLD:ssl.crt
scp CLE.key admin@DOMAIN.TLD:ssl.key

Depuis Windows, scp est exploitable avec putty, en téléchargeant l’outil pscp

pscp -P 22 CERTIFICAT.crt admin@DOMAIN.TLD:ssl.crt
pscp -P 22 CLE.key admin@DOMAIN.TLD:ssl.key

Dès lors que les fichiers sont sur le serveur, le reste du travail se fera sur celui-ci. En ssh ou en local.

Or, rien n’indique que sont les .crt ou .key et comment nous les obtenons ou même d’où nous chargeons les informations avec les commandes scp ou pscp.
En tout cas, moi je ne l’ai pas vu. D’où ma façon de tourner en rond pendant un moment. :smile:

Il est pour moi plus simple de montrer que la demande peut-être faite du serveur avant d’aller voir l’agence de certification qui nous correspond. Ce que j’ai mis dans mon tutoriel du coup du petit 1 au petit 3. :slight_smile:

#5

Je pense que si on pouvait mettre des couleurs pour simplifier la lecture de mon document (avec toutes les remarques que je fais, j’ai peur que les gens se perdent…

Bref ajout d’une ligne concernant les sous-domaines créés après l’application des certificats : les nouveaux certificats automatiquement appliqués correspondent à des certificats autosignés. Il faut copier son duo certificat et clef (les deux fichiers *.pem) dans le dossier du nouveau sous-domaine pour qu’ils soient aussi reconnus par les navigateurs.

#6

Merci et bravo pour ce travail de relecture et d’explications. C’est toujours utile car les docs. pour des raisons évidentes de compacité sont parfois.souvent opaques. Belle explication de texte.

1 Like