Problème de certificat SSL après un renew avec cozy-coclyco

Bonjour à tous,

Hier, en voulant tester la nouvelle application “Notes”, je l’ai installé et j’ai dû généré à nouveau mes certificats (cozy-coclyco regenerate). J’ai reload nginx et tout fonctionne à merveille depuis mon navigateur. Je n’avais cependant pas remarqué que tous mes connecteurs ne pouvaient plus se mettre à jour.

Tous tombent avec l’erreur CANNOT_FIND_ACCOUNT. En regardant les logs, j’ai pu identifier que les connecteurs n’arrivent pas à effectuer une requête à /status/ car ils ne peuvent pas vérifier le certificat. En me rendant directement sur l’url en question depuis mon navigateur, je ne rencontre aucun soucis. Cependant, via curl, je rencontre effectivement un problème.

Voici les logs d’un de mes Konnector (les logs des autres Konnectors sont similaires) :

Note: J’ai remplacé mon domaine par cozy.tools :wink:

Jan  9 13:11:25 cozy[12415]: time="2020-01-09T13:11:25+01:00" level=error msg="request to https://cozy.tools/status/ failed, reason: unable to verify the first certificate" domain=cozy.tools job_id=0b8f5ed6691ac665357c1f568a00a30a nspace=jobs slug=cic worker_id=konnector/0
Jan  9 13:11:25 cozy[12415]: time="2020-01-09T13:11:25+01:00" level=error msg="Account aac68....22a7c5 does not exist" domain=cozy.tools job_id=0b8f5ed6691ac665357c1f568a00a30a nspace=jobs slug=cic worker_id=konnector/0
Jan  9 13:11:25 cozy[12415]: time="2020-01-09T13:11:25+01:00" level=warning msg="Error from konnector" domain=cozy.tools job_id=0b8f5ed6691ac665357c1f568a00a30a nspace=jobs slug=cic worker_id=konnector/0
Jan  9 13:11:25 cozy[12415]: time="2020-01-09T13:11:25+01:00" level=error msg=CANNOT_FIND_ACCOUNT domain=cozy.tools job_id=0b8f5ed6691ac665357c1f568a00a30a nspace=jobs slug=cic worker_id=konnector/0
Jan  9 13:11:25 cozy[12415]: time="2020-01-09T13:11:25+01:00" level=info msg="Konnector failure: CANNOT_FIND_ACCOUNT" account_id=aac682162f02b5bad4f62f20cf22a7c5 domain=cozy.tools exec_time=12.498624968s job_id=0b8f5ed6691ac665357c1f568a00a30a nspace=jobs slug=cic version=1.4.0-d65d63b1ad59c9757d05b0c7f52a2c8a83e1880e worker_id=konnector/0
Jan  9 13:11:25 cozy[12415]: time="2020-01-09T13:11:25+01:00" level=error msg="error while performing job: CANNOT_FIND_ACCOUNT" domain=cozy.tools job_id=0b8f5ed6691ac665357c1f568a00a30a nspace=jobs worker_id=konnector/0

La conf Nginx :

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        ssl_certificate /etc/ssl/private/cozy.tools.crt;
        ssl_certificate_key /etc/ssl/private/cozy.pem;

        server_name *.cozy.tools cozy.tools;
        access_log /var/log/nginx/cozy.tools.log;
        error_log /var/log/nginx/cozy.tools.error.log;

        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload;";
        client_max_body_size 1g;

        location / {
                proxy_pass http://localhost:8080;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection $connection_upgrade;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $remote_addr;
        }
}

Les fichiers :

ls -lah /etc/ssl/private/cozy.tools.crt /etc/ssl/private/cozy.pem
-rw-r--r-- 1 root root 2,0K janv.  9 12:32 /etc/ssl/private/cozy.tools.crt
-rw-r--r-- 1 root root  241 avril 15  2019 /etc/ssl/private/cozy.pem

Une idée de ce qui pourrait entrainer ce soucis ?

J’ai résolu le problème de certificat en passant directement via certbot (j’en ai profité pour générer un wildcard). Tous mes Konnectors fonctionnent à nouveau et je n’ai plus aucun problème (y compris en curl).

1 Like

Salut Orandin,

J’aime les gens qui font les questions et les réponses :wink:

Est-ce que tu as compris ce que certbot a fait de plus que coclyco ? Il y a probablement un détail de configuration qui nous échappe et qu’il faudrait qu’on corrige.

Je ne sais pas ce qui explique que cela fonctionne mieux avec certbot. En comparant la forme des fichiers utilisés avec ceux générés par coclyco, j’ai remarqué que le fichier fullchain.pem contient 2 certificats, contre 1 avec coclyco. Je ne sais pas si cela peut être la cause.

La clef privée avec cerbot est également beaucoup plus grande que celle de coclyco.

Voici les quelques remarques que j’ai pu constater. J’ignore quelle est la véritable root cause. :confused:

1 Like

Merci beaucoup, je soupçonnais un truc dans le genre, je pense que ça correspond au unable to verify the first certificate. Il manque probablement un certificat intermédiaire dans fullchain.pem. De mémoire, fullchain.pem devrait contenir une concaténation du certificat du site et de la chaîne de certificats permettant de remonter à un certificat racine. (soit cert.pem et chain.pem).

@aeris

1 Like

On n’utilise pas le fullchain.pem avec coclyco. Et je viens de regarder, le fichier généré est bien avec les 2 certificats dans (le cert du FQDN du cozy + l’intermédiaire de Let’s Encrypt). Donc de ce côté c’est correct et ce qui est attendu.

JE confirme j’avais déjà eu ce soucis.
j’avais manuellement concaténer les certificats (je crois que j’avais posté sur le forum à ce sujet)

1 Like

HEllo,

Je déterre car cela a replanté suite à ma période de 90j …
en creusant un peu dans le code je vois ça ici ligne 270+

pem = OpenSSL.crypto.dump_certificate_request(
OpenSSL.crypto.FILETYPE_PEM, csr)
Logger.info(“Request issuance for %s”, domains)
order = self.__acme.new_order(pem)
order = self.__perform_http01(order)
crt = order.fullchain_pem

Chez moi je suis obligé de concaténer à la main mondomaine.fr.crt avec letsencrypt.crt et de faire pointer mon nginx vers le nouveau .crt que j’ai créé.

Un regenerate ne fonctionne pas.

EDIT: je précise que cela fonctionnait bien il y a plusieurs mois. et que j’ai eu ce soucis en octobre novembre (date à laquelle il ya eu des commit apparemment)

Je ne sais pas comment ça se fait chez toi, mais le code est bien conforme à l’attendu.
Le code est bien en fullchain_pem qui comme son nom l’indique contient la chaîne complète, l’usage est conforme à l’exemple de Let’s Encrypt et un certificat émis ce matin sur notre environnement de test est correct avec les 2 certificats nécessaires, celui du domaine et l’intermédiaire de Let’s Encrypt :

Difficile donc de dire plus que « ça marche chez moi ™ » et que le code est a priori correct…

Pour rappel, le certificat racine de Let’s Encrypt ne doit pas être inclu dans la chaîne de certification.
https://discussions.qualys.com/thread/11234

Par acquit de conscience, j’ai testé hors staging chez Let’s Encrypt, rien à signaler non plus :

J’ai tenté en créant une nouvelle instance.
Aucun soucis de chainage.

Par contre sur mes deux anciennes instances j’ai ce soucis, résolu comme décrit plus haut.

DE ce que j’ai compris le soucis c’est que je vais avoir une handshake plus longue (ca ne me dérange pas outre mesure).

Je regarderai plus tard comment corriger ça proprement, je n’ai pas vraiment envie de recréer mes instances.

Merci @aeris en tout cas pour tes recherches :slight_smile:

1 Like

En dehors de la latence du handshake, c’est source possible d’un problème de sécurité, le dernier certificat (la racine) étant supposé être disponible dans le magasin de certificat du navigateur et non fournit par le serveur.
Dans des cas bien précis (qui ne devraient pas arriver sur un navigateur standard mais peuvent arriver sur les trucs plus exotiques type node/konnectors, ie avec une implémentation de la vérification d’authentification TLS plus fragile voire manuelle), ça veut potentiellement dire que le certificat va du coup être accepté sans aucune vérification de la racine par rapport à la liste des CA de confiance du système…

Et l’instance n’a aussi aucun rapport avec l’émission du certificat sinon récupérer la liste des domaines à signer… :man_shrugging: