La réponse est oui. En bref, il s'agit d'un certificat de nom alternatif de sujet (SAN) qui contient des IP où vous verriez généralement des entrées DNS. Le type de certificat n'est pas limité aux IP publiques - cette restriction est uniquement imposée par une autorité de signature plutôt que par la technologie. Je voulais juste clarifier ce point. Je soupçonne que vous voulez simplement vous débarrasser de ce message d'invite non sécurisé sur vos sites Web et appareils internes sans avoir à payer et à vous embêter à leur donner des noms DNS et à payer une autorité de certification pour qu'elle émette un certificat tous les ans ou tous les deux ans. Vous ne devriez PAS essayer de convaincre le monde entier que votre adresse IP est un site web réputé et les gens devraient se sentir à l'aise pour fournir leurs informations de paiement. Maintenant que nous avons établi pourquoi aucune organisation réputée ne veut émettre ce type de certificat, faisons-le nous-mêmes avec un certificat SAN auto-signé. En interne, j'ai un certificat de confiance qui est déployé sur tous nos hôtes, puis je signe ce type de certificat avec lui et tous les appareils deviennent fiables. Faire cela ici dépasse le cadre de la question mais je pense que c'est pertinent pour la discussion car la question et la solution vont de pair. Pour être concis, voici comment générer un certificat SAN individuel auto-signé avec des adresses IP. Étendez la liste d'adresses IP à l'ensemble de votre sous-réseau et utilisez un seul certificat pour tout.
#!/bin/bash
#using: OpenSSL 1.1.1c FIPS 28 May 2019 / CentOS Linux release 8.2.2004
C=US ; ST=Confusion ; L=Anywhere ; O=Private\ Subnet ; EMAIL=admin@company.com
BITS=2048
CN=RFC1918
DOM=company.com
SUBJ="/C=$C/ST=$ST/L=$L/O=$O/CN=$CN.$DOM"
openssl genrsa -out ip.key $BITS
SAN='\n[SAN]\nsubjectAltName=IP:192.168.1.0,IP:192.168.1.1,IP:192.168.1.2,IP:192.168.1.3,IP:192.168.1.4,IP:192.168.1.5,IP:192.168.1.6,IP:192.168.1.7,IP:192.168.1.8,IP:192.168.1.9,IP:192.168.1.10'
cp /etc/pki/tls/openssl.cnf /tmp/openssl.cnf
echo -e "$SAN" >> /tmp/openssl.cnf
openssl req -subj "$SUBJ" -new -x509 -days 10950 \
-key ip.key -out ip.crt -batch \
-set_serial 168933982 \
-config /tmp/openssl.cnf \
-extensions SAN
openssl x509 -in ip.crt -noout -text
4 votes
Cette question peut être intéressant : vous pouvez mais l'adresse IP doit être dans une entrée SAN de type adresse IP, pas dans le CN du DN sujet.
39 votes
LetsEncrypt ne le fait pas. """" x.x.x.x est une adresse IP. L'autorité de certification de Let's Encrypt ne délivrera pas de certificats pour une adresse IP nue."""
2 votes
Le Forum des navigateurs C/A fournit un ensemble de politiques d'émission. Elle est évidemment suivie par les navigateurs. L'AC/B n'autorise plus les adresses IP. Un autre ensemble de politiques de délivrance est maintenu par l'IETF. L'ICP de l'IETF s'appelle PKIX. PKIX autorise les adresses IP. PKIX est suivi par la plupart des logiciels [libres ?], comme cURL et Wget. Je n'arrive pas à comprendre le cert de 1.1.1.1 . Il devrait être interdit selon les politiques de l'AC/B. Peut-être que l'AC/B a changé ses politiques.
5 votes
@jww : comme plusieurs réponses le disent correctement, CABforum interdit Réservé Adresses IP -- principalement les plages privées dans RFC1918 et RFC6598 plus quelques autres comme 127 pour localhost et les exemples dans la documentation. Ils permettent explicitement Public Adresses IP ; voir BR 3.2.2.5.