Merci pour la réponse détaillée, c'est très instructif.
À part obtenir, de la part d’une CA reconnue, un certificat intermédiaire autorisé à signer des certificats finaux sans limitation, je ne vois pas.
Ça serait la solution la plus simple.
Si je comprend bien c'est justement comme cela que fonctionne let's encrypt : les certificats issus de let's encrypt sont signés par identTrust qui est reconnu par les navigateurs; ce qui permet que let's encrypt même tout jeune soit lui aussi reconnu par les navigateurs. J'ai bon ?
Mais j'imagine que d'obtenir ce type de certificat est hors de prix ?
...
Pour la suite je fais des précisions/réflexions issue de mes recherches faites depuis (mais vous pouvez me corriger si je fais fausse route) :
Question subsidiaire : peut on faire un certificat pour une adresse IP (voir adresse IP locale*) et non un DNS ? *et oui je voulais bien parler d'adresses privées au sens RFC 1918. Mais ma question portait aussi sur les IP publique (genre 172.217.18.227)
Après quelque recherches j'ai trouvé quelqu'un qui a posé exactement la même question que moi sur stackoverflow et la réponse qui y est faite est qu'une adresse IP peut être utilisé à la place d'un hostname (RFC 2818). Mais effectivement il ne précise pas le type d'IP et les "Private Address Space" font sûrement exception.
Je suis certain que je vais avoir des clients qui vont utiliser des IP du coup pour les IP publiques ça devrait être bon, mais pas les privées.
Donc, pour mon dispositif l'idéal serait que le client puisse :
1. Installer ses certificats sur le dispositif (que le dispositif utilisera pour signer son certificats https). En fait j'ai découvert depuis que les switchs hp et cisco font comme ça.
2. Pour rendre l'utilisation du SSL plus simple pour l'utilisateur je pense implémenter un client let's encrypt (ça marche à la condition que mon dispositif soit mis en place de sorte qu'il soit accessible depuis internet)
Le point 2 ça serait vraiment la "classe à Dallas", et du coup j'ai regardé le principe de fonctionnement de let's encrypt à l'air plutôt simple. Mais par contre les clients let's encrypt ont l'air assez complexe... parce qu'ils automatisent tout et font la config de apache/nginx.
Et la limite du port 80 pour l’authentification HTTP-01 risque d'être gênante : je vois pas mal de nos clients utiliser des ports complètement exotique pour faire une redirection publique sur leur dispositif, du coup pas de let's encrypt pour eux.
Je pensais pouvoir faire du https simplement depuis que ARM avait rendu libre PolarSSL, mais je découvre que la certification est peut être un problème plus ardu a bien intégrer.
[^] # Re: Est ce une solution Certification pour objets connectés
Posté par trancheX . En réponse à la dépêche Reparlons de Let’s Encrypt. Évalué à 1.
Merci pour la réponse détaillée, c'est très instructif.
Ça serait la solution la plus simple.
Si je comprend bien c'est justement comme cela que fonctionne let's encrypt : les certificats issus de let's encrypt sont signés par identTrust qui est reconnu par les navigateurs; ce qui permet que let's encrypt même tout jeune soit lui aussi reconnu par les navigateurs. J'ai bon ?
Mais j'imagine que d'obtenir ce type de certificat est hors de prix ?
...
Pour la suite je fais des précisions/réflexions issue de mes recherches faites depuis (mais vous pouvez me corriger si je fais fausse route) :
Après quelque recherches j'ai trouvé quelqu'un qui a posé exactement la même question que moi sur stackoverflow et la réponse qui y est faite est qu'une adresse IP peut être utilisé à la place d'un hostname (RFC 2818). Mais effectivement il ne précise pas le type d'IP et les "Private Address Space" font sûrement exception.
Je suis certain que je vais avoir des clients qui vont utiliser des IP du coup pour les IP publiques ça devrait être bon, mais pas les privées.
Donc, pour mon dispositif l'idéal serait que le client puisse :
1. Installer ses certificats sur le dispositif (que le dispositif utilisera pour signer son certificats https). En fait j'ai découvert depuis que les switchs hp et cisco font comme ça.
2. Pour rendre l'utilisation du SSL plus simple pour l'utilisateur je pense implémenter un client let's encrypt (ça marche à la condition que mon dispositif soit mis en place de sorte qu'il soit accessible depuis internet)
Le point 2 ça serait vraiment la "classe à Dallas", et du coup j'ai regardé le principe de fonctionnement de let's encrypt à l'air plutôt simple. Mais par contre les clients let's encrypt ont l'air assez complexe... parce qu'ils automatisent tout et font la config de apache/nginx.
Et la limite du port 80 pour l’authentification HTTP-01 risque d'être gênante : je vois pas mal de nos clients utiliser des ports complètement exotique pour faire une redirection publique sur leur dispositif, du coup pas de let's encrypt pour eux.
Je pensais pouvoir faire du https simplement depuis que ARM avait rendu libre PolarSSL, mais je découvre que la certification est peut être un problème plus ardu a bien intégrer.