Aller au contenu

Certificat renouvelé mais les clients VNP affichent certificat expiré ?


Messages recommandés

Posté(e) (modifié)

Bonjour à tous,

Mes caractéristiques logiciels sont les suivantes :

##############################################

version VPN Server : 1.3.11.2777
modèle du NAS Synology : DS1515
version : DSM 6.2.2-24922 Update 3

Emission du certificat : Let's Encrypt Authority X3
pour CardDAV Server, FTPS, Paramètres système par défaut, HyperBacup Vault, Cloud Station Server, Réception des journaux, VPN Server
Durée : 3 mois

Client OpenVPN GUI v11.15.0.0 - A Windows GUI for OpenVPN

###############################################

Messages d'erreurs et connexion refusée :

Après expiration du certificat (au bout de 3 mois), j'ai effectué son renouvellement manuel sans difficulté et sans message de notification quelconque.

Sur le DSM le certificat s'affiche au Vert et est valide jusqu'au 20/09/2020. Jusqu'ici tout va bien.

Seulement lorsque mes clients OpenVPN essaient de se connecter, ils affichent tous les messages d'erreur suivants, dont celui qui affirme que le certificat a expiré (?)

Mon Jun 22 13:54:28 2020 TCP_CLIENT link remote: [AF_INET]******************:1194
Mon Jun 22 13:54:29 2020 VERIFY ERROR: depth=0, error=certificate has expired: CN=*****************
Mon Jun 22 13:54:29 2020 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
Mon Jun 22 13:54:29 2020 TLS_ERROR: BIO read tls_read_plaintext error
Mon Jun 22 13:54:29 2020 TLS Error: TLS object -> incoming plaintext read error
Mon Jun 22 13:54:29 2020 TLS Error: TLS handshake failed

Pour tenter de résoudre mon problème, j'ai exporté la configuration à partir du DSM vers la configuration des clients OpenVPN mais sans résultat.

Je précise qu'à part le renouvellement du certificat sur le DSM, aucune autre changement n'a été effectué, y compris sur la configuration du client OpenVPN

N'étant pas un averti des problèmes liés aux certificats, est-ce que quelqu'un ici peut m'aider ?

--
Terranon

 

certGUIonDSM.PNG

Modifié par Terranon
Complément d'informations
Posté(e)

Bonjour à tous,

Je viens de mettre à jour le DSM vers sa dernière version : la 6.2.3-25426 Update 2

Mais le problème demeure. Les clients OpenVPN affichent toujours les mêmes messages d'erreurs.

Quelqu'un a-t-il une piste de recherche à me donner à défaut d'avoir déjà rencontré ce problème ?

--

Terranon

Posté(e)

@Terranon

Bonjour,

  1. Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre. Cela dit rassures-toi il n'est pas trop tard pour bien faire ...

  2. Pour ton problème, je crains que tu ne mélanges les choses.
    Il y a le certificat LE pour certifier que tu es bien le propriétaire de ton domaine et qui est utilisé dans les connexions sécurisées HTTPS d'une part et le certificat intégré à OpenVPN et qui lui est propre pour certifier tes connexions VPN.
    Revois ta configuration OpenVPN et régénère le fichier de configuration que tu importeras sur tes clients. Ce fichier ".ovpn" contient le certificat en question. Edites-le et tu verras ...

Cordialement

oracle7😉

 

  • 4 semaines après...
Posté(e) (modifié)

Bonjour,

Je viens de constater le même problème chez moi.
Après renouvellement du certificat Let's Encrypt j'ai bien réexporté la configuration OpenVpn et réintégré le nouveau certificat dans mes fichiers de configuration OpenVpn client.
Malgré cela j'ai toujours la même erreur de certificat expiré lorsque j'essaye de me connecter au NAS via OPenVpn

Modifié par Thierry94
Posté(e)

@Thierry94

Bonjour,

Il y a 7 heures, Thierry94 a dit :

Après renouvellement du certificat Let's Encrypt j'ai bien réexporté la configuration OpenVpn et réintégré le nouveau certificat dans mes fichiers de configuration OpenVpn client.

OK mais question idiote : as-tu ensuite vidé le cache de ton navigateur et relancé celui-ci avant de te connecter avec OpenVPN ?

Si NON alors, il serait normal qu'il ait toujours en mémoire l'ancien certificat donc celui qui est expiré.

Cordialement

oracle7😉

Posté(e)

@Thierry94

Bonjour,

Cela fait peut être doublon mais j'ai aussi importé le certificat LE sur mon tél Android après l'avoir converti en ".pfx" avec acme.sh (voir le TUTO au §9).

La connexion OpenVPN s'établit sans problème.

J'ai comparé le "ca.cer" de mon certificat LE avec la seconde partie du certificat inclus dans le fichier ".ovpn". C'est bien le même contenu. Il n'y a que la première partie du certificat inclus dans le fichier ".opvn" que je ne sais faire matcher avec quoi que ce soit. Je pense que ce doit être la clé de chiffrement OpenVPN, mais je n'en suis pas sûr.

Cordialement

oracle7😉

  • 2 semaines après...
Posté(e)

Bonsoir Messieurs,

Je commençais à me demander si mon problème allait intéresser quelqu'un.

Thierry94, je retiens votre solution pour la mettre en pratique d'ici peu.

Existe-t-il des logs à consulter sur le DSM pour chercher des traces éventuelles de cette anomalie ?

Oracle7, je me manquerais de me présenter dans la rubrique PRESENTATION.

A bientôt ! Je vous fais un retour.

 

Posté(e) (modifié)

Bonjour à tous,

J'ai reproduit la solution de Thierry94. C'est-à-dire l'idée de la désinstallation / réinstallation du VPN Server.

Première méthode :

- Sauvegarde des paramètres du VPN Server via Hyper Backup

- Arrêt et désinstallation du VPN Server sans supprimer sa base.

- Réinstallation du VPN Server

- Activation et paramétrage du OpenVPN

>>> message d'erreur concernant le port 1194 <<<

Ce port est déjà utilisé. Choisissez un autre port.

- J'ai changé le port : 1192 sur OpenVPN et le routeur.

- Arrêt / Démarrage du VPN Server

- Exportation des fichiers de la configuration du VNP Server vers le client OpenVPN

- Tentative de connexion du client OpenVNP

>>> message d'erreur à l'étape suivante : <<<

Sun Sep 20 12:10:31 2020 TCP: connect to [AF_INET]xxx.xxx.xxx.xxx:1192 failed: Unknown error

Ci-joint le log de connexion du client OpenVPN

Qu'en pensez-vous ?

--

Terranon

err01.PNG

logvpnclient01.PNG

Modifié par Terranon
Posté(e)

@Terranon

Bonjour,

Le 17/09/2020 à 22:33, Terranon a dit :

Oracle7, je me manquerais de me présenter dans la rubrique PRESENTATION.

Alors ?

Astuce : Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait).

il y a 25 minutes, Terranon a dit :

- Sauvegarde des paramètres du VPN Server via Hyper Backup

- Arrêt et désinstallation du VPN Server sans supprimer sa base.

  • Quel intérêt de sauvegarder les paramètres si tu ne les restores pas après ?
  • De plus l'objectif de la désinstallation/réinstallation du package VPN Serveur est bien de repartir sur des bases saines et donc pas avec d'anciens paramètres qui peuvent être corrompus. Logique, non ?
  • ????? de quelle base tu parles ?

il y a 26 minutes, Terranon a dit :

- J'ai changé le port : 1192 sur OpenVPN et le routeur.

Cela ne sert à rien, le serveur OpenVPN est prévu pour fonctionner et utiliser naturellement le port 1194. Ce port lui est réservé par l'IANA.

il y a 31 minutes, Terranon a dit :

Sun Sep 20 12:10:31 2020 TCP: connect to [AF_INET]xxx.xxx.xxx.xxx:1192 failed: Unknown error

De plus, le serveur OpenVPN utilise en standard le protocole UDP pour des raisons principalement de performances. Le protocole TCP n'est à utiliser que si la qualité de ta connexion internet ou les restrictions imposées par ton FAI rendent son utilisation impraticable ou impossible.De plus, même si le protocole TCP est bien plus fiable, encapsuler TCP dans TCP aboutit parfois à des résultats assez ... étranges, sans parler d'une demande en CPU plus importante.

Enfin, si cela ne marche pas avec la ligne "remote @IP externe 1194" et si tu as un domaine "tonDomaine.tld" ou "xxxxx.synology.me" : essaies à tout hasard avec "remote tonDomaine.tld 1194" ou "remote xxxxx.synology.me 1194".

Donc, je t'invites à faire une installation propre du package VPN Serveur et de paramétrer correctement OpenVPN selon ses standards.

Cordialement

oracle7😉

Posté(e)

Désinstallation / réinstallation du VPN Server.

Deuxième méthode :

- Arrêt et désinstallation du VPN Server en supprimant sa base cette fois-ci.

- Réinstallation du VPN Server

- Activation et paramétrage du OpenVPN

>>> message d'erreur concernant le port 1194 <<<

Ce port est déjà utilisé. Choisissez un autre port.

- Cette notification disparaît si je change le protocole : de TCP à UDP

- J'ai rechangé le port et le protocole : 1194 en UDP sur le VPN Serveur et le routeur.

- Arrêt / Démarrage du VPN Server

- Exportation des fichiers de la configuration du VNP Server vers le client OpenVPN

- Tentative de connexion du client OpenVNP

>>> message d'erreur à l'étape suivante : <<<

Sun Sep 20 13:24:35 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Sep 20 13:24:35 2020 TLS Error: TLS handshake failed

Ci-joint le log de connexion du client OpenVPN

Je continue de chercher la solution.

En attente de vos contributions.

--

Terranon

udp.PNG

errovpnclient02.PNG

@oracle7

Je suis concentré sur mon problème Oracle7. Cela devient malheureusement urgent compte-tenu du contexte sanitaire actuellement.

Ce problème se manifeste dans un cadre professionnel. Je promets de me présenter ultérieurement si tu veux bien.

La suppression de la base de données du VPN Server est une option lorsque l'on lance l'assistant de suppression du VPN Server (ci-joint)

 

supprdbvpnserver.PNG

Posté(e)

@oracle7

il y a une heure, oracle7 a dit :

Quel intérêt de sauvegarder les paramètres si tu ne les restores pas après ?

C'est la première fois que je supprime un VPN Server. Cela m'a paru être une option car la sauvegarde ne concerne visiblement que du paramétrage. Paramètres inchangés et qui étaient opérationnels avant le problème.

Et puis cela me permet de prendre en main ce type de procédure.

Je n'ai cependant pas restauré la sauvegarde. J'ai reparamétré manuellement pour tester en repartant à blanc.

sauvegrde.PNG

@oracle7

il y a une heure, oracle7 a dit :

Cela ne sert à rien, le serveur OpenVPN est prévu pour fonctionner et utiliser naturellement le port 1194. Ce port lui est réservé par l'IANA.

C'est noté. Merci de cette précision.

Posté(e)

@Terranon

Bonjour,

Bon eh bien on avance !

Plus de problème de port 1194 "déjà utilisé 😅 et aux vues du Log la connexion ne "butte" plus que sur un problème de négociation TLS.

  • Le port 1194 est-il bien transféré (NAT/PAT) de la Box/Routeur vers le NAS ?
  • Le port 1194 est-il bien ouvert/autorisé dans le pare-feu du NAS ?
  • La ligne "redirect-gateway def1" est-elle dé-commentée dans le fichier de config ".ovpn" ?
  • As-tu aussi insérée l'option "dhcp-option DNS 10.8.0.1" ?

Cordialement

oracle7😉

 

Posté(e)

@oracle7

il y a 26 minutes, oracle7 a dit :
  • Le port 1194 est-il bien transféré (NAT/PAT) de la Box/Routeur vers le NAS ?

Oui

  • Le port 1194 est-il bien ouvert/autorisé dans le pare-feu du NAS ?

Oui

  • La ligne "redirect-gateway def1" est-elle dé-commentée dans le fichier de config ".ovpn" ?

Oui

  • As-tu aussi insérée l'option "dhcp-option DNS 10.8.0.1" ?

Je viens de la dé-commenter mais c'est sans effet

 

Mes réponses dans le texte Oracle7

Posté(e) (modifié)

@oracle7 et @Thierry94

Bonjour Messieurs,

J'attends à présent le moment où je vais pouvoir redémarrer le NAS. Je suis à court d'idées.

Je vous joins les sections actives de mon fichier VPNConfig.ovpn au cas où vous y verriez des manques ou des erreurs :

dev tun
tls-client

remote --------------- 1194

pull

proto udp4

script-security 2

remote-cert-tls server

reneg-bytes 64000000

comp-lzo

reneg-sec 0

cipher BF-CBC

auth SHA1

auth-nocache

auth-user-pass

 

Bien à vous,

--

Terranon

Modifié par Terranon
Posté(e) (modifié)

@Terranon

Bonjour,

Quelques anomalies :

  • C'est "proto upd" tout court en v4 et non pas "proto udp4"
  • "remote-cert-tls server" : pour utiliser cette fonctionnalité, voir ici et as-tu généré tes certificats de serveur avec le keyUsage défini sur digitalSignature, keyEncipherment et le extendedKeyUsage à "serverAuth"
  • C'est "cipher AES-256-CBC" et non pas "cipher BF-CBC"
  • C'est "auth SHA512" et non pas "auth SHA1"
  • C'est quoi "reneg-bytes 64000000" je n'ai pas trouvé dans la doc OpenVPN ? EDIT : Finalement j'ai trouvé !
    Citation
    --reneg-bytes n
     

    Renegotiate data channel key after n bytes sent or received (disabled by default with an exception, see below). OpenVPN allows the lifetime of a key to be expressed as a number of bytes encrypted/decrypted, a number of packets, or a number of seconds. A key renegotiation will be forced if any of these three criteria are met by either peer.

    If using ciphers with cipher block sizes less than 128-bits, --reneg-bytes is set to 64MB by default, unless it is explicitly disabled by setting the value to 0, but this is HIGHLY DISCOURAGED as this is designed to add some protection against the SWEET32 attack vector. For more information see the --cipher option.

    Du coup pourquoi spécifier cette option si l'option "--cypher" l'est déjà ?

  • Manque une ligne "key-direction 1"
  • Manque une ligne "explicit-exit-notify"

Au final, si j'étais toi je commencerai par faire fonctionner tout cela avec le fichier de configuration de base avant de le "bricoler" ... mais ce n'est que mon avis.

PS : Vu trop tard, ta réponses @Thierry94

Cordialement

oracle7😉

Modifié par oracle7
Posté(e)

@oracle7

Le 21/09/2020 à 13:55, oracle7 a dit :

C'est "proto upd" tout court en v4 et non pas "proto udp4"

Après la désinstallation / réinstallation du serveur VPN, l'UDP link remote: [AF_INET]*****************:1194, affichait l'IPv6 du serveur VPN.

Ignorant l'impact j'ai forcé en utilisant proto upd4

 

 

@oracle7

Le 21/09/2020 à 13:55, oracle7 a dit :

"remote-cert-tls server" : pour utiliser cette fonctionnalité, voir ici et as-tu généré tes certificats de serveur avec le keyUsage défini sur digitalSignature, keyEncipherment et le extendedKeyUsage à "serverAuth"

# Do not display WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
 

@oracle7

Le 21/09/2020 à 13:55, oracle7 a dit :

C'est quoi "reneg-bytes 64000000" je n'ai pas trouvé dans la doc OpenVPN ? EDIT : Finalement j'ai trouvé !

# Do not display WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
# Mitigate the attack by forcing frequent rekeying with reneg-bytes 64000000

J'ai inhibé reneg-bytes 64000000 car l'avertissement n'apparaît plus.

@oracle7

Le 21/09/2020 à 13:55, oracle7 a dit :
  • Manque une ligne "key-direction 1"
  • Manque une ligne "explicit-exit-notify"

Je vais regarder ces sections. Merci.

Posté(e)

@oracle7 et @Thierry94

Conclusion : la désinstallation du VPN Server semble avoir été la solution. Dans mon cas, j'ai dû aussi redémarrer le NAS.

Accessoirement, savez-vous si cette anomalie est journalisée dans des journaux sur le NAS ?

Dans tous les cas, merci à vous pour l'aiguillage.

--

Terranon

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.