Bonjour les pros,

Dans l'attente de la fibre, je m'occupe et j'ai decidé de migrer mes 2 raspberry (Adguard et jeedom) vers des VMs de mon NAS. Histoire de reduire le nombre de cables / prises dans la baie et également m'affranchir des problèmes de cartes SD bref.

La conf en place est la suivante :
Freebox Revolution (bridge) <> UDM Pro <> QNAP TVS1282 <> Vms

J'utilise la fonctionnalité intégrée à QTS5 de reverse proxy, et tout ce petit monde fonctionne correctement, j'arrive à accéder à mes sites (Vms) en utilisant des noms de domaine prédéfinis.

Là où ça coince un peu, c'est que le Nas dispose de son propre certificat (xxx.myqnapcloud.com), et que mes VMs disposent de certificats letsencrypt. Du coup, quand je me connecte en SSL, le navigateur me sort un warning Cert_Invalid, car pour lui les deux noms ne correspondent pas (et il a raison).

La solution la plus simple, serait de prendre un certificat Wildcard et le mettre partout, mais je suis d'abord à la recherche d'une solution sans frais.

Merci d'avance si vous avez des idées.

Merci, je vais regarder cela avec attention.

En attendant, j'ai trouvé la solution.
Sur le Qnap, je peux remplacer le certificat d'origine par un letsencrypt, et surtout je peux lui donner des noms alternatifs.
Du coup, mon nas est accessible via XXX.mondomaine.com, mon jeedom sous jeedom.mondomaine.com et ainsi de suite.

une bonne chose de faite

Letsencrypt gère aussi gratuitement les wildcard, c'est juste un mécanisme de vérification différent (challenge DNS au lieu du http)
https://letsencrypt.org/docs/faq/#does-let-s-encrypt-issue-wildcard-certificates

Merci pour toutes ces réponses.

Il y a un souci avec le reverse proxy de Qnap apparemment, qui ne gère pas correctement les certificats intermédiaire.

En clair, si je redirige les ports 80 et 443 du routeur directement sur le NAS, le certificat cité plus haut est détecté comme correct (incluant Racine et intermédiaire)

Par contre, si je redirige vers le reverse proxy et ensuite vers le NAS (pour test), les certificats Racine et Intermédiaire sont détectés comme expirés.

J'étais avec le support Qnap toute la journée hier, et finalement un rapport de bug a été soumis, le tech ne voyait pas non plus pourquoi cela ne fonctionnait pas.

On a deux chaînes de certification, dont une qui est expirée depuis le 1er octobre (DST Root CA X3).

Cf le sujet dédié : 1er octobre 2021: nombreux changements pour Let's Encrypt

Le certificat expiré est utilisé par Android 7.0 et inférieur (Android ne vérifie pas la date, ce qui sauve 1/3 des smartphone d'une mort certaine) et il y a en effet des problèmes avec des composants Linux qui sont en échec a cause de cette expiration (il ne testent pas la seconde chaîne de certification qui est valide). La solution est de retirer le certificat expiré DST Root CA X3 du système. On en parle ici

Ce qui est gênant, c'est l'opposition entre les vieilles versions d'Android et OpenSSL 1.0.2.

Si le serveur envoie le ISRG Root X1 signé par DST Root CA X3 :
 - Les vielles versions d'Android contiennent la racine DST Root CA X3, et ne vérifient pas son expiration, donc ça passe.
 - Si la racine DST Root CA X3 est embarquée, OpenSSL 1.0.2 voit la chaîne avec une racine expirée et refuse, même si la racine ISRG Root X1 est présente.

Si le serveur envoie le ISRG Root X1 racine (ou juste le reste de la chaîne) :
 - Les vielles versions d'Android n'embarquent pas la racine ISRG Root X1, donc la chaîne est invalide.
 - OpenSSL 1.0.2 fonctionne si la racine ISRG Root X1 est embarquée.

Si on regarde les dépendances, apt utilise GnuTLS.
GnuTLS avait un bug similaire à OpenSSL 1.0.2, ça a été corrigé en 3.6.14.
Pas de chance, Ubuntu 20.04 a toujours GnuTLS 3.6.13.