Safari ne peut pas établir une connexion sécurisée en V4.1 sous Debian 10

[Rajstopy]

Bonjour à tous,

Il n’est pas encore trop tard pour souhaiter une très belle année 2022 à tous les membres de ce forum !

Je commence l’année avec quelques soucis, car j’ai enfin pris le temps de m’attaquer à la migration vers la V4. Cela faisait des mois que je repoussais l’échéance et maintenant je sais pourquoi, car c’est vraiment l’enfer de tout remettre d’équerre

Bref, ça commence à marchotter mais je rencontre encore des soucis, notamment au niveau de mes scripts PHP, dont certains ne passent plus

Bref, le souci auquel je m’attèle en ce moment, c’est que depuis que j’ai posé mon propre certificat SSL, je n’arrive plus à me connecter ni depuis Safari, ni depuis le client Safari de mon iPhone. Avec Firefox par exemple, aucun problème. Lorsque j’utilise le certificat auto-signé de base avec Apache, aucun souci. Ce qui me fait penser que la ma génération de certificat doit ne pas convenir aux versions récentes d’iMachins. A noter que j’ai plusieurs autres serveurs pour lesquels je n’ai aucun souci de génération de certificat.

Je vous mets ci-dessous la méthode employée, peut-être que l’un d’entre vous pourra me mettre sur une piste :

[ req ]

default_bits = 2048

prompt = no

default_md = sha256

req_extensions = req_ext

distinguished_name = dn

[ dn ]

C=FR

ST=XXX

L=XXX

O=XXX

emailAddress=XXX

CN = jeedom.XXX.net

[ req_ext ]

subjectAltName = @alt_names

extendedKeyUsage = serverAuth

keyUsage = keyEncipherment, dataEncipherment

[ alt_names ]

DNS.1 = jeedom

DNS.2 = jeedom.XXX.net

DNS.3 = localhost

IP.1 = 192.168.10.20

IP.2 = 127.0.0.1

Générer les clés :

openssl req -new -sha256 -nodes -out jeedom.csr -newkey rsa:2048 -keyout jeedom.key -config jeedom.cnf

Signer le certificat sur le serveur avec l’autorité interne.

Placer le certificat nouvellement signé vers le bon répertoire /etc/ssl/certs/

Modifier la conf Apache :

cd /etc/apache2/sites-enabled

vi default-ssl.conf

SSLCertificateFile /etc/ssl/certs/jeedom.crt

SSLCertificateKeyFile /etc/ssl/private/jeedom.key

Reload Apache :

systemctl reload apache2

Je suis sous Debian 10… Je ne comprends pas pourquoi mes Safari bronchent…

[Mips]

Bonjour,

Un certificat auto-signe va poser problème dans beaucoup de cas, vous feriez mieux de mettre un certificat let’s encrypt par exemple.

[Rajstopy]

Bonjour et merci pour votre réponse.

Il n’y a pas de raison que cela pose problème . Mon instance Jeedom n’est pas ouverte sur l’Internet, donc hors de question d’utiliser un certificat Let’s Encrypt. De nombreuses entreprises utilisent une autorité de certification interne ce qui est mon cas d’ailleurs. Je penche plutôt pour un problème de parametrage lié à la façon dont j’ai généré mon nouveau certif.

[Rajstopy]

Après une bonne nuit, je viens de trouver la solution. Très con en fait et comme je le présumais, lié à un problème de paramétrage du certificat.

C’est le message d’erreur de Chrome qui m’a mis sur la voie : ERR_SSL_KEY_USAGE_INCOMPATIBLE

C’est en fait ma spécification d’usage de clé qui était moisie (paramètre keyUsage). Il faut spécifier nonRepudiation, ce qui semble logique quand on y réfléchit. Du coup, le bon fichier de conf est le suivant, si ça peut aider…

[ req ]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[ dn ]
C=FR
ST=XXX
L=XXX
O=XXX
emailAddress=XXX
CN = jeedom.XXX.net

[ req_ext ]
subjectAltName = @alt_names
extendedKeyUsage = serverAuth
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ alt_names ]
DNS.1 = jeedom
DNS.2 = jeedom.XXX.net
DNS.3 = localhost
IP.1 = 192.168.10.5
IP.2 = 127.0.0.1

Et comme disait un prof de maths que j’adorais quand on lui posait une question : « Tu vas répondre toi-même à ta question »