stacked certificates - whats wrong?

[errtee]

Hi All,

we work since <10 years with an openvpn Version 2.4.0, now there are some hundreds of clients registered, live connected around 400...480
Now the SSL certificates are near EOL ;-(
With this amount of Clients we need a smooth change of the certificates.

We tried this, the "improved migration":
https://blog.hexonet.net/content/migrat ... or-openvpn
but we dont have the ca-key anymore, so this is impossible for us...

The new idea is, to stack two server certificates, the old one and a new one, that signed the same (old) server key.
But the "stacked certificate" don't seems to work...

It looks like the server only sends the "first" of the stacked certificates to the client (or the client takes only the first?).

what can be wrong?

This is how we are stacking the certificates (not the real filenames):

Code: Select all

#cat old.crt new.pem >stacked1.pem
#cat new.pem old.crt >stacked2.pem

(https://community.openvpn.net/openvpn/w ... ate_Chains)


the subject line of the old certificate: C=de, ST=sax, L=wurzen, O=d..., OU=vpn, CN=dl-vpn, emailAddress=ronny@r...
and the old ca: C=de, ST=sax, L=wurzen, O=d..., OU=vpn, CN=d...-vpn, emailAddress=ronny@r...
and the new one: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=ganzneu
the CA of the new one: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=DLCA

Logs:

Client using new ca, old server certificate "first":

Code: Select all

Wed Jul  3 14:32:37 2019 TLS: Initial packet from [AF_INET]213.239.195.109:1194, sid=c64a124b a37b30de
Wed Jul  3 14:32:37 2019 VERIFY ERROR: depth=0, error=unable to get local issuer certificate: C=de, ST=sax, L=wurzen, O=d..., OU=vpn, CN=dl-vpn, emailAddress=ronny@r...
Wed Jul  3 14:32:37 2019 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Jul  3 14:32:37 2019 TLS Error: TLS object -> incoming plaintext read error
Wed Jul  3 14:32:37 2019 TLS Error: TLS handshake failed

Client using new ca, new server certificate "first":

Code: Select all

Wed Jul  3 15:05:33 2019 TLS: Initial packet from [AF_INET]213.239.195.109:1194, sid=ffd67e52 c3f2e7a1
Wed Jul  3 15:05:33 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jul  3 15:05:34 2019 VERIFY OK: depth=1, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=DLCA
Wed Jul  3 15:05:34 2019 VERIFY OK: depth=0, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=ganzneu

Client using old ca, old server certificate "first":

Code: Select all

Wed Jul  3 14:41:03 2019 TLS: Initial packet from [AF_INET]213.239.195.109:1194, sid=dcff5968 198509cd
Wed Jul  3 14:41:03 2019 VERIFY OK: depth=1, C=de, ST=sax, L=wurzen, O=d..., OU=vpn, CN=d...-vpn, emailAddress=ronny@r...
Wed Jul  3 14:41:03 2019 VERIFY OK: depth=0, C=de, ST=sax, L=wurzen, O=d..., OU=vpn, CN=dl-vpn, emailAddress=ronny@r...

Client using old ca, new server certificate "first":

Code: Select all

Wed Jul  3 15:05:49 2019 TLS: Initial packet from [AF_INET]213.239.195.109:1194, sid=f734d283 94417aa5
Wed Jul  3 15:05:49 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jul  3 15:05:49 2019 VERIFY ERROR: depth=0, error=unable to get local issuer certificate: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=ganzneu
Wed Jul  3 15:05:49 2019 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Wed Jul  3 15:05:49 2019 TLS Error: TLS object -> incoming plaintext read error
Wed Jul  3 15:05:49 2019 TLS Error: TLS handshake failed

OpenSSL 1.1.0k 28 May 2019
# cat /etc/debian_version
9.9

any idea?


sunny greetings,

Ronny and Holm

[errtee]

quick update:

to avoid missunderstandings:
the setup is a bit special, the certificate based authentication works only for the server to the clients,
the clients authenticate with name/password to the server ( most of the used routers 10 years ago does not support own certificates;-)

we are also curious for alternative ideas

cu, Ronny and Holm

[TinCanTech]

Code: Select all

                  │15:47:32     tincantech | kitsune1: any ideas on that link above about stacked cert ?                              │ anonymip    
                  │16:03:45       kitsune1 | tincantech: I do not expect two independent server certs in one file to work -- a chain  │ Anthaas
                  │                        | of certs should, but they cant use that option as they lost the old CA key. I think the  │ Antoine-   
                  │                        | only option  is to use two servers, gradually migrating all clients to the new one.      │ APTX       
                  │16:12:21     tincantech | kitsune1: thanks, i was only curious about the point of the stacked server.crt, i should │ axsuul     
                  │                        | have more carefully read the ovpn wiki ;-)                                               │ aykut      
                  │16:13:01     tincantech | the wiki is a stacked CA not server cert                                                 │ Azelphur 

[errtee]

Hi TinCanTech,

thanks for the answer...

but...

I do not expect two independent server certs in one file to work -- a chain of certs should

how does this work?
https://blog.hexonet.net/content/migrat ... or-openvpn

"Improved Migration - Step 1" in the graphic, server.pem
imho this certs are also not chained
the intermediate cert is signed by the old ca
the only common is the serverkey... isn't it the same situation like we try?
why does this works? does it?

only option is to use two servers, gradually migrating all clients to the new one

yes, this is our planD, but it has many disantvantages
and: does it really work?

cu,

Ronny and Holm

[TinCanTech]

how does this work?

I suggest you contact the authors of the article and question them.

Your experimentation shows how openvpn behaves.

In future, do not lose your CA key.