Bonjour, Le comportement de ces navigateur est logique avec la philosophie d’une connexion sécurisée par une autorité. Celle-ci doit être reconnue pour assurer la confidentialité des échanges. La plupart des utilisateurs/constructeurs laissent le certificat « snake oil » de base mais, par évidence, ce système ne peut être considéré comme sûr. Une réponse certainement bête mais … avez-vous demandé au constructeur de ces équipement s’il n’était pas possesseur d’un vrai certificat ? Visiblement, c’est lui qui impose l’utilisation d’un traitement par certificat, qu’il propose donc une solution certifiée. Une autre solution puisque vous dites que la machine n’est pas sur un réseau connecté : passer sur une connexion sans cryptage. Ce ne sera pas moins sûr que le certificat de base et si cet équipement est réellement isolé, cela ne présente pas véritablement de danger à moins d’être directement et physiquement connecté dessus, donc à côté. Autre solution si vous avez accès à la configuration de la machine, est-ce que vous ne pouvez pas y coller un certificat d’autorité et le faire reconnaître une fois pour toute par le navigateur (Chrome, Firefox) pour qu’il cesse de vous em… ? Cordialement > Le 20 janv. 2019 à 20:16, Jack.R <jack.r@free.fr> a écrit : > > Bonjour, > > J'utilise des contrôleurs d'équipements industriels qui ont une base > Debian Stretch customisée par le fabriquant de la carte CPU. > Ces équipements embarquent un certain nombre de services (serveur > web, serveur ssh, serveur FTP, ...) > Certaines connexions sont chiffrées en SSL avec un certificat > auto-signé. > Les versions actuelles de navigateurs (firefox, chrome, ...) > déclenchent systématiquement un avertissement, il faut mettre une > exception et, si c'est faisable, la rendre permanente. > > Imaginez que vous êtes l'opérateur qui tous les matins démarre sa > machine avec une belle interface web et qui doit créer/accepter > l'exception pour un certificat auto-signé dont il n'a pas la moindre > idée de ce que c'est. > > Je cherche un moyen de mettre un certificat (ou une chaîne) valide et > reconnu par les navigateurs comme de confiance. > > Une solution style let's encrypt (certbot) ne me semble pas valide car: > - les équipements n'ont pas de connexion avec internet (impossible de > renouveler le certificat), > - l'ip et le nom de machine sont définis par l'utilisateur final et en > fonction du secteur d'installation il peut même y avoir du DHCP, > - les équipements ne sont pas forcément reliés au réseau usine (pas de > possibilité d'utiliser un serveur interne avec une chaîne de > certificats), > - dans la même machine, je peux avoir plusieurs de ces équipements > (impossible d'avoir un nom de machine/domaine -fqdn- identique) > > mkcert comme utilisé ici: > https://lehollandaisvolant.net/?d=2019/01/07/22/57/47-localhost-et-https > ne cadre pas car le navigateur n'est pas nécessairement celui embarqué > par l'équipement, on peut effectuer un accès distant pour un écran > déporté affichant par exemple le status de l'équipement. > > Si certains ont des pistes de recherches, je suis preneur car mes > recherches avec "trusted certificat industrial equipment" et un > apt-cache search certificate ne me retourne pas de résultat qui me > semblent intéressants. > > Rassurez-moi, les éditeurs de navigateur ont bien pensé à ce cas de > figure lorsqu'ils on décidé "d'imposer" HTTPS et TLS? > Je me pose la question lorsque je lis la portion "For native apps > talking to web apps" de: > https://letsencrypt.org/docs/certificates-for-localhost/ > > -- > Jack.R > -- Pierre Malard |\ _,,,---,,_ /,`.-'`' -. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <--
Attachment:
signature.asc
Description: Message signed with OpenPGP