Topic: Openvpn-bridge

[didwedo]

bonjour à tous,
par les temps qui courent j'ai un souci VPN que peut-être d'autres ont...

en son temps j'avais installé tout ça avec tunnelblick sur mac, créé la version serveur, un client...
tout fonctionnait bien.

puis récemment avec les événements du corona, j'ai installé ce user unique sur tous les postes de travail et chacun est reparti à la maison avec son ordi.

évidemment, une fois tous connectés, chacun piquait l'IP de l'ancien connecté.

j'ai donc créé d'autres utilisateurs, avec les mêmes paramètres que le premier que je me garde.
et bien le premier se connecte sans souci, les autres, qui ont seulement le fichier pk12 de différent me font des erreurs certificat.

à n'y rien comprendre.
une idée? voir les lois ci-dessous...

avez-vous pu insérer de multiple utilisateurs?

je précise que je suis en TAP car TUN est déprécié des macs récents comme indiqué sur le site d'Openvnp.

merci à tous pour votre aide.
salutations Chris


2020-03-23 11:36:36.204618 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=CH, ST=VD, L=Lausanne, O=DOMAIN, OU=Certificate Authority, CN=DOMAIN PHPki Certificate Authority, emailAddress=webmaster@DOMAIN.ch
2020-03-23 11:36:36.204718 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2020-03-23 11:36:36.204759 TLS_ERROR: BIO read tls_read_plaintext error
2020-03-23 11:36:36.204788 TLS Error: TLS object -> incoming plaintext read error
2020-03-23 11:36:36.204814 TLS Error: TLS handshake failed

[gieres]

Bonjour,
Je ne suis pas capable d'interpréter le fichier journal mais il faut créer dans PHPKi un certificat par utilisateur. Donc ça ne m'étonne pas que seul le premier VPN connecté fonctionne.
On a un serveur avec plusieurs utilisateurs en télétravail et plusieurs certificats différents : le couple user.pem et user-key.pem. Seuls le certificat d'autorité et le takey.pem sont communs.
Tout fonctionne bien.
Je suis preneur de la procédure (avec les captures d'écrans) s'il s'agit d'un Mac pour compléter le wiki : https://wiki.contribs.org/OpenVPN_Bridge/fr
Et de toute remarque de ce qui ne serait pas clair sur le wiki, comme le fait qu'il faut un certificat par utilisateur.
Bon travail.

[didwedo]

Bonjour,
Je ne suis pas capable d'interpréter le fichier journal mais il faut créer dans PHPKi un certificat par utilisateur. Donc ça ne m'étonne pas que seul le premier VPN connecté fonctionne.
On a un serveur avec plusieurs utilisateurs en télétravail et plusieurs certificats différents : le couple user.pem et user-key.pem. Seuls le certificat d'autorité et le takey.pem sont communs.
Tout fonctionne bien.
Je suis preneur de la procédure (avec les captures d'écrans) s'il s'agit d'un Mac pour compléter le wiki : https://wiki.contribs.org/OpenVPN_Bridge/fr
Et de toute remarque de ce qui ne serait pas clair sur le wiki, comme le fait qu'il faut un certificat par utilisateur.
Bon travail.

c'est pourtant bel et bien le cas, j'ai créé un nouvel utilisateur avec ses propres PEM comme vous le dites...
dans le fichier de config dupliqué j'ai changé le pk12, mais rien à faire, même passé en Ca, user.pem et user-key.pem rien ni fait...

j'ai suivi toute la procédure.
ce qui m'a alerté est le fait que TAP serait valable our une seule connection, TUN serait multiple, possible?

merci bcp pour votre aide, chris

[gieres]

Je n'enregistre pas le PKCS #12 mais chacun des 3 certificats et la première fois, j'ai trouvé cela bien complexe car à l'enregistrement, ils s’appellent tous .pem sauf la clé privée. Le seul moyen de ne pas se mélanger les pinceaux est de les renommer à chaque téléchargement et de bien s'organiser (pas de téléphone qui sonne !). Un moyen de les distinguer est leur taille. Dans le wiki, j'ai précisé :
Une nouvelle page s'ouvre avec, à gauche une liste déroulante des différents fichiers du certificat :

    PKCS12 Bundle ;
    PEM certificate qui correspond au certificat en lui-même (environ 1,9 kio en 2048 bits) ;
    PEM key qui est la clé privé du certificat (environ 1,7 kio en 2048 bits) ;
    PEM Bundle
    PEM Bundle w/Root qui est le certificat racine ou CA (environ 5,4 kio en 2048 bits).

Attention, quand vous allez demander le téléchargement des fichiers 2, 3 et 5, les fichiers 2 et 5 vont être téléchargés sous le même nom avec l'extension .pem. Renommer rapidement le n°2 en *-cert.pem et le n°5 en *-CA.pem pour éviter toute confusion.

Est-ce que ce ne serait pas là qu'il y aurait un mélange dans la config du serveur ?

[didwedo]

Je n'enregistre pas le PKCS #12 mais chacun des 3 certificats et la première fois, j'ai trouvé cela bien complexe car à l'enregistrement, ils s’appellent tous .pem sauf la clé privée. Le seul moyen de ne pas se mélanger les pinceaux est de les renommer à chaque téléchargement et de bien s'organiser (pas de téléphone qui sonne !). Un moyen de les distinguer est leur taille. Dans le wiki, j'ai précisé :
Une nouvelle page s'ouvre avec, à gauche une liste déroulante des différents fichiers du certificat :

    PKCS12 Bundle ;
    PEM certificate qui correspond au certificat en lui-même (environ 1,9 kio en 2048 bits) ;
    PEM key qui est la clé privé du certificat (environ 1,7 kio en 2048 bits) ;
    PEM Bundle
    PEM Bundle w/Root qui est le certificat racine ou CA (environ 5,4 kio en 2048 bits).

Attention, quand vous allez demander le téléchargement des fichiers 2, 3 et 5, les fichiers 2 et 5 vont être téléchargés sous le même nom avec l'extension .pem. Renommer rapidement le n°2 en *-cert.pem et le n°5 en *-CA.pem pour éviter toute confusion.

Est-ce que ce ne serait pas là qu'il y aurait un mélange dans la config du serveur ?

alors j'ai bien vu passer ce post, j'ai testé, aucun changement...
je pense que le pk12 fait bien son effet et est plus simple à gérer, mais j'ai testé hier et aucun changement.

je vais redémarrer open vp-bridge car je n'y ai plus accès avec mon premier compte :-/

encore merci de prendre le temps pour nous.

PS : concernant le mélange j'y ai aussi pensé mais après vérification il n'en est rien.
je serais même prêt à une discussion skype ou téléphone.

[didwedo]

Je n'enregistre pas le PKCS #12 mais chacun des 3 certificats et la première fois, j'ai trouvé cela bien complexe car à l'enregistrement, ils s’appellent tous .pem sauf la clé privée. Le seul moyen de ne pas se mélanger les pinceaux est de les renommer à chaque téléchargement et de bien s'organiser (pas de téléphone qui sonne !). Un moyen de les distinguer est leur taille. Dans le wiki, j'ai précisé :
Une nouvelle page s'ouvre avec, à gauche une liste déroulante des différents fichiers du certificat :

    PKCS12 Bundle ;
    PEM certificate qui correspond au certificat en lui-même (environ 1,9 kio en 2048 bits) ;
    PEM key qui est la clé privé du certificat (environ 1,7 kio en 2048 bits) ;
    PEM Bundle
    PEM Bundle w/Root qui est le certificat racine ou CA (environ 5,4 kio en 2048 bits).

Attention, quand vous allez demander le téléchargement des fichiers 2, 3 et 5, les fichiers 2 et 5 vont être téléchargés sous le même nom avec l'extension .pem. Renommer rapidement le n°2 en *-cert.pem et le n°5 en *-CA.pem pour éviter toute confusion.

Est-ce que ce ne serait pas là qu'il y aurait un mélange dans la config du serveur ?

@400000005e78d07a0edb5a34 Authenticate/Decrypt packet error: packet HMAC authentication failed
@400000005e78d07a0edb8914 TLS Error: incoming packet authentication failed from [AF_INET]213.55.220.240:41079

[ReetP]

PKCS12 - because it is easy.

I have made some updates to PHPKi which will be out soon.

Once change was to modify the certificate names so you get name-cert.pem name-key.pem etc so it is less confusing

0.82.20 is in smetest

It also has some other small fixes but needs testing.

[ReetP]

@400000005e78d07a0edb5a34 Authenticate/Decrypt packet error: packet HMAC authentication failed
@400000005e78d07a0edb8914 TLS Error: incoming packet authentication failed from [AF_INET]213.55.220.240:41079

Probably something wrong with your TA key setup.

https://community.openvpn.net/openvpn/ticket/1199

[didwedo]

Probably something wrong with your TA key setup.

https://community.openvpn.net/openvpn/ticket/1199

I haven't changed takey, why would it work with one user and not the other ???

[ReetP]

I haven't changed takey, why would it work with one user and not the other ???

Because logically something, somewhere, is not the same but you haven't give enough information for us to see.

So you better do a proper report and show your configs so we can have a look.

Restart openvpn.

Get the client to connect and then save the log.

Show us the server and clients configs.

I also suggest you try a general search on the interwebs for a phrase like "packet HMAC authentication failed TLS error"

eg:

https://forums.openvpn.net/viewtopic.php?t=26176

[didwedo]

hello,

i don't know where is located the server configuration.

here is the first client, it work...

proto udp
dev tap
nobind
remote 62.220.130.113 1194
tls-client
tls-auth takey.pem 1
remote-cert-tls server
resolv-retry infinite
persist-key
auth-user-pass
pkcs12 team.p12
cipher AES-256-CBC
compress lzo
pull

here is the second client, it fail...
(that's my account)

proto udp
dev tap
nobind
remote 62.220.130.113 1194
tls-client
tls-auth takey.pem 1
remote-cert-tls server
resolv-retry infinite
persist-key
auth-user-pass
pkcs12 chris.p12
cipher AES-256-CBC
compress lzo
pull

here is the log...

2020-03-26 14:23:15.604830 *Tunnelblick: macOS 10.13.6 (17G65); Tunnelblick 3.8.2 (build 5480); prior version 3.8.1 (build 5400)
2020-03-26 14:23:15.906447 *Tunnelblick: Attempting connection with chris using shadow copy; Set nameserver = 769; monitoring connection
2020-03-26 14:23:15.907301 *Tunnelblick: openvpnstart start chris.tblk 56329 769 0 1 0 1098098 -ptADGNWradsgnw 2.4.8-openssl-1.1.1e
2020-03-26 14:23:15.932953 *Tunnelblick: openvpnstart starting OpenVPN
2020-03-26 14:23:16.749524 OpenVPN 2.4.8 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Mar 22 2020
2020-03-26 14:23:16.749637 library versions: OpenSSL 1.1.1e  17 Mar 2020, LZO 2.10
2020-03-26 14:23:16.751661 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:56329
2020-03-26 14:23:16.751700 Need hold release from management interface, waiting...
2020-03-26 14:23:17.172016 *Tunnelblick: openvpnstart log:
     Loading tap-notarized.kext
     OpenVPN started successfully.
     Command used to start OpenVPN (one argument per displayed line):
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.8-openssl-1.1.1e/openvpn
          --daemon
          --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Skirrs-SLibrary-SApplication Support-STunnelblick-SConfigurations-Schris.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_1098098.56329.openvpn.log
          --cd /Library/Application Support/Tunnelblick/Users/kirrs/chris.tblk/Contents/Resources
          --machine-readable-output
          --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5480 3.8.2 (build 5480)"
          --verb 3
          --config /Library/Application Support/Tunnelblick/Users/kirrs/chris.tblk/Contents/Resources/config.ovpn
          --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/kirrs/chris.tblk/Contents/Resources
          --verb 3
          --cd /Library/Application Support/Tunnelblick/Users/kirrs/chris.tblk/Contents/Resources
          --management 127.0.0.1 56329 /Library/Application Support/Tunnelblick/pddnllmdjiempkdmafcabdffgefibeaoplbkagll.mip
          --management-query-passwords
          --management-hold
          --script-security 2
          --route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -a -d -f -m -w -ptADGNWradsgnw
          --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -a -d -f -m -w -ptADGNWradsgnw
          --route-pre-down /Applications/Tunnelblick.app/Contents/Resources/client.route-pre-down.tunnelblick.sh -9 -a -d -f -m -w -ptADGNWradsgnw
2020-03-26 14:23:17.184626 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:56329
2020-03-26 14:23:17.230369 MANAGEMENT: CMD 'pid'
2020-03-26 14:23:17.230456 MANAGEMENT: CMD 'auth-retry interact'
2020-03-26 14:23:17.230516 MANAGEMENT: CMD 'state on'
2020-03-26 14:23:17.230586 MANAGEMENT: CMD 'state'
2020-03-26 14:23:17.230685 MANAGEMENT: CMD 'bytecount 1'
2020-03-26 14:23:17.231990 *Tunnelblick: Established communication with OpenVPN
2020-03-26 14:23:17.233246 *Tunnelblick: >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
2020-03-26 14:23:17.235873 MANAGEMENT: CMD 'hold release'
2020-03-26 14:23:17.283133 *Tunnelblick: Obtained VPN username and password from the Keychain
2020-03-26 14:23:17.283983 MANAGEMENT: CMD 'username "Auth" "chris"'
2020-03-26 14:23:17.284061 MANAGEMENT: CMD 'password [...]'
2020-03-26 14:23:17.284214 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-03-26 14:23:17.310465 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-03-26 14:23:17.310499 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2020-03-26 14:23:17.310987 TCP/UDP: Preserving recently used remote address: [AF_INET]62.220.130.113:1194
2020-03-26 14:23:17.311041 Socket Buffers: R=[196724->196724] S=[9216->9216]
2020-03-26 14:23:17.311055 UDP link local: (not bound)
2020-03-26 14:23:17.311067 UDP link remote: [AF_INET]62.220.130.113:1194
2020-03-26 14:23:17.311141 MANAGEMENT: >STATE:1585228997,WAIT,,,,,,
2020-03-26 14:23:17.345902 MANAGEMENT: >STATE:1585228997,AUTH,,,,,,
2020-03-26 14:23:17.345963 TLS: Initial packet from [AF_INET]62.220.130.113:1194, sid=770f7df7 9dd292a5
2020-03-26 14:23:17.349798 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2020-03-26 14:23:17.381303 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=CH, ST=VD, L=Lausanne, O=Didwedo, OU=Certificate Authority, CN=Didwedo PHPki Certificate Authority, emailAddress=webmaster@didwedo.ch
2020-03-26 14:23:17.381447 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2020-03-26 14:23:17.381476 TLS_ERROR: BIO read tls_read_plaintext error
2020-03-26 14:23:17.381508 TLS Error: TLS object -> incoming plaintext read error
2020-03-26 14:23:17.381526 TLS Error: TLS handshake failed
2020-03-26 14:23:17.384066 SIGUSR1[soft,tls-error] received, process restarting
2020-03-26 14:23:17.384108 MANAGEMENT: >STATE:1585228997,RECONNECTING,tls-error,,,,,
2020-03-26 14:23:17.387313 MANAGEMENT: CMD 'hold release'
2020-03-26 14:23:17.387379 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-03-26 14:23:17.387510 TCP/UDP: Preserving recently used remote address: [AF_INET]62.220.130.113:1194
2020-03-26 14:23:17.387549 Socket Buffers: R=[196724->196724] S=[9216->9216]
2020-03-26 14:23:17.387563 UDP link local: (not bound)
2020-03-26 14:23:17.387575 UDP link remote: [AF_INET]62.220.130.113:1194
2020-03-26 14:23:20.206090 TLS: Initial packet from [AF_INET]62.220.130.113:1194, sid=33a3f629 08753570
2020-03-26 14:23:20.255091 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=CH, ST=VD, L=Lausanne, O=Didwedo, OU=Certificate Authority, CN=Didwedo PHPki Certificate Authority, emailAddress=webmaster@didwedo.ch
2020-03-26 14:23:20.255145 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2020-03-26 14:23:20.255159 TLS_ERROR: BIO read tls_read_plaintext error
2020-03-26 14:23:20.255169 TLS Error: TLS object -> incoming plaintext read error
2020-03-26 14:23:20.255178 TLS Error: TLS handshake failed
2020-03-26 14:23:20.255389 SIGUSR1[soft,tls-error] received, process restarting

thanks for your help

[ReetP]

Look in /etc/openvpn/something

[ReetP]

Also srarch the internet:

VERIFY ERROR: depth=1, error=self signed certificate in certificate chain

The cerificates are probably not the same somehow.

Are you missing the CA in on the client?

How did you install the certificates in the client??

[didwedo]

Look in /etc/openvpn/something

here is the openvpn.conf

push "dhcp-option DOMAIN gw.didwedo.ch"
push "dhcp-option DNS 192.168.3.1"
push "dhcp-option WINS 192.168.3.1"

mtu-test
cipher AES-256-CBC
passtos
nice 5

management localhost 11194 management-pass.txt

# Clients options
client-config-dir ccd
max-clients 20
comp-lzo adaptive
push "comp-lzo adaptive"

status-version 2
status bridge-status.txt
suppress-timestamps
verb 3

[didwedo]

Also srarch the internet:

The cerificates are probably not the same somehow.
Are you missing the CA in on the client?
How did you install the certificates in the client??

normally the certificate is in the pk12 right?
for installing the certificate, tunnelblick manages it, right?

[ReetP]

normally the certificate is in the pk12 right?

Depends what you are using!!!!!

for installing the certificate, tunnelblick manages it, right?

Usually.

Be quite clear. You need either:

A Public CA certificate

Personal certificates - type VPN Client

A Public user certificate
A Private user certificate

Or:

A pk12 with all three will be combined into one file - CA + public + private

You will need a separate TA Key file.

Make sure that the certificate details all match correctly. You must ONLY have one CA. ALL user certificates must be created/signed by that CA. I think somewhere you have got some certificates muddled up.

[didwedo]

i don't understand why my use1 can connect and why my user2 can't???

[ReetP]

i don't understand why my use1 can connect and why my user2 can't???

Because user 1 has the right certificates setup correctly and user 2 does not. It is as simple as that.

If you read that error online it is the same thing over and over again. So, best check it first, properly.

What did you do differently with the certificates?

You can check each client certificate like this:

Code: [Select]

cd /opt/phpki/phpki-store/CA
openssl verify -CAfile ./certs/cacert.pem ./newcerts/100001.pem
eg:

Code: [Select]

openssl verify -CAfile ./certs/cacert.pem ./newcerts/100001.pem
You can also check that the details match as well

Code: [Select]

openssl x509 -subject -issuer -noout -in ./certs/cacert.pem
openssl x509 -subject -issuer -noout -in ./newcerts/100001.pem

Here is some more reading on the subject (which is exactly what I just had to do myself)

https://duckduckgo.com/?q=openvpn+VERIFY+ERROR%3A+depth%3D1%2C+error%3Dself+signed+certificate+in+certificate+chain&t=canonical&ia=web

Please tell us what versions of software you have as well please

rpm -qa |grep phpki
rpm -qa |grep openvpn

[didwedo]

hello, sorry for my absence,
the week was difficult and i didn't use a computer all weekend.
you are very nice to help me, thank you.

rpm -qa |grep phpki
smeserver-phpki-0.2-3.el6.sme.noarch
phpki-0.82-19.el6.sme.noarch

rpm -qa |grep openvpn
openvpn-2.4.8-1.el6.x86_64
smeserver-openvpn-bridge-2.1-10.el6.sme.noarch

openssl verify -CAfile ./certs/cacert.pem ./newcerts/100001.pem
OK

openssl x509 -subject -issuer -noout -in ./certs/cacert.pem
subject= /C=CH/ST=VD/L=Lausanne/O=Didwedo sarl/OU=Certificate Authority/CN=PHPki Certificate Authority/emailAddress=webmaster@didwedo.ch
issuer= /C=CH/ST=VD/L=Lausanne/O=Didwedo sarl/OU=Certificate Authority/CN=PHPki Certificate Authority/emailAddress=webmaster@didwedo.ch

I must say that from the beginning I have this error:

An error occured while updating the CRL for OpenVPN-Bridge
because openssl didn't recognize the file as a valid CRL.
Below is the copy of the latest CRL downloaded from
https://192.168.3.1/phpki/index.php?stage=dl_crl_pem

[ReetP]

hello, sorry for my absence,
the week was difficult and i didn't use a computer all weekend.
you are very nice to help me, thank you.

We all have lives....

rpm -qa |grep phpki
smeserver-phpki-0.2-3.el6.sme.noarch
phpki-0.82-19.el6.sme.noarch

rpm -qa |grep openvpn
openvpn-2.4.8-1.el6.x86_64
smeserver-openvpn-bridge-2.1-10.el6.sme.noarch

OK

openssl verify -CAfile ./certs/cacert.pem ./newcerts/100001.pem
OK

Do that for ALL the certificates....

And check this for all certificates as well:

Code: [Select]

openssl x509 -subject -issuer -noout -in ./newcerts/100001.pem

openssl x509 -subject -issuer -noout -in ./certs/cacert.pem
subject= /C=CH/ST=VD/L=Lausanne/O=Didwedo sarl/OU=Certificate Authority/CN=PHPki Certificate Authority/emailAddress=webmaster@didwedo.ch
issuer= /C=CH/ST=VD/L=Lausanne/O=Didwedo sarl/OU=Certificate Authority/CN=PHPki Certificate Authority/emailAddress=webmaster@didwedo.ch

OK.

I must say that from the beginning I have this error:

An error occurred while updating the CRL for OpenVPN-Bridge
because openssl didn't recognize the file as a valid CRL.
Below is the copy of the latest CRL downloaded from
https://192.168.3.1/phpki/index.php?stage=dl_crl_pem

Never leave out errors when reporting an issue - they may or may not be important.

Revocation list - checks if any certificates have been revoked.

In this case it should not be fatal but you should check it. There is a crontab that should get the CRL from your PHPKI server.

Code: [Select]

# Update OpenVPN bridge's CRL\n"
5 * * * * root /etc/e-smith/events/actions/openvpn-bridge-update-crl 2>&1 /dev/null\n"
You need to make sure the openvpn server can read the crl from the PHPKI server ( I don't know if they are on the same server or different server) - test with a browser.

Try testing using the command line:

Code: [Select]

/etc/e-smith/events/actions/openvpn-bridge-update-crl
If so then make sure the this file exists: /etc/openvpn/bridge/pub/cacrl.pem

[didwedo]

ok, I am not very comfortable handling crontabs...

/etc/e-smith/events/actions/openvpn-bridge-update-crl
ok
If so then make sure the this file exists: /etc/openvpn/bridge/pub/cacrl.pem
the cert exist with no error

and I do not dare to re-install everything because at the moment there is no one on site and the only account that works is essential.

maybe we will wait and when the time comes I mandate you to fix this, what do you think?

normally all certificates are revoked except the bridge and the user admin. I will check the others.
thank you

[ReetP]

ok, I am not very comfortable handling crontabs...

Usually just scripts in a file that get run periodically. There is nothing to worry about.

the cert exist with no error

OK, so you have the cacrl.pem

and I do not dare to re-install everything because at the moment there is no one on site and the only account that works is essential.

Understandable. You should have ssh access really.....

maybe we will wait and when the time comes I mandate you to fix this, what do you think?

If I need the money that badly I will let you know

normally all certificates are revoked except the bridge and the user admin. I will check the others.
thank you

Ahhhh.

Have you thought about what you have said here???? I mean REALLY thought about it?

All certificates EXCEPT the bridge and the admin are revoked.

So, you have certs for the:

1. bridge server itself
2. admin
3. team
4. chris

I think you better check how many of these are valid?

Can you also show:

Code: [Select]

ll /etc/openvpn/bridge/pub

Here's mine (updated by the cronjob at 15.05 - should be every hour at 5 minutes past)

-rw-r--r-- 1 root root 1401 Mar 30 15:05 cacrl.pem

[didwedo]

oups
-rw-r--r-- 1 root admin 1858 20 mars  15:48 cacert.pem
-rw-r--r-- 1 root root   934  5 août   2019 cacrl.pem
-rw-r--r-- 1 root admin 1990 20 mars  15:48 cert.pem
-rw-r--r-- 1 root admin  248 20 mars  15:48 dh.pem

i have an SSH access, don't worry

i have certs for the:

1. bridge server itself
2. team
3. chris

# openssl verify -CAfile ./certs/cacert.pem ./newcerts/10000F.pem
./newcerts/10000F.pem: OK
# openssl verify -CAfile ./certs/cacert.pem ./newcerts/100006.pem
./newcerts/100006.pem: OK
# openssl verify -CAfile ./certs/cacert.pem ./newcerts/100019.pem
./newcerts/100019.pem: OK

you should also understand that I am only a webmaster, having drifted in development, then a bit of linux admin, but totally limited.

[didwedo]

Afin de fermer ce ticket, je vais vous expliquer l'erreur que j'ai faite.

Après un crash serveur, j'ai ré-installé SME depuis zèro, re-créé le VPN et l'utilisateur.
Par fainéantise je me suis contenté de remplir les champs avec ceux de l'ancienne installation et non pas les nouveaux certificats générés.

Donc l'ancien utilisateur fonctionnait et les nouveaux me généraient des erreurs.
Tout est rentré dans l'ordre maintenant que j'ai mis les bons certificats dans l'OpenVPN-Brigde.

Merci à tous ceux qui m'ont aidé.
à bientôt
chris