📜 ⬆️ ⬇️

OpenVPN, easy reissue of root certificate

Good day. The background is as follows: ten years ago I raised the infrastructure of a network of mobile phone salons, distributed over the region. The 1C: Enterprise 7.7 system was used as the accounting solution in the distributed database mode. For data exchange, the usual windows network folder was used, which was accessed through the OpenVPN tunnel. And once a week ago, the exchange of information between the center and the periphery completely stopped. For some reason, the thought immediately crept in - ten years had passed (it was for this period that the root certificate was made). Analysis of the logs confirmed the problem, the scheme has proven itself well over these ten years, but the time has come. And now, to re-generate the entire amount of client and server keys / certificates ??? No, you can do a little easier ...

OpenSSL allows you to reissue the certificate and sign it with the old private key, while maintaining the structure of the Modulus certificate and the new certificate successfully verifies the old client certificates.

Create a new certificate:

openssl x509 -in ca.crt -days 3650 -out ca-new.crt -signkey ca.key 

We get the answer:
')
 Getting Private key 

and new certificate ca-new.crt

Let's check the client certificate with a new root certificate:

 openssl verify -CAfile ca-new.crt client9.crt 

All is well:

 client9.crt: OK 

The next command can look at the contents of the certificate and make sure that the new and old Modulus certificate is the same:

 openssl x509 -noout -text -in ca-new.crt 

Everything seems to be very good, we are sending a new certificate, after renaming it in the same way as the old one, with instructions to the user where to put it (we overwrite the old one).

Restart the service on the server and see how the clients connect. Unfortunately, not all clients did it successfully. Some have received in the log:

 Tue Mar 21 15:12:18 2017 VERIFY ERROR: depth=1, error=certificate signature failure: /C=RU... 

It was here that I had to lose a few hours, in the end it turned out that the client certificate verification also fails on client computers:

 openssl verify -CAfile ca-new.crt client9.crt 

The openssl version (as part of OpenVPN) turned out to be old and did not want to check successfully.

Accordingly, the problematic clients had to update OpenVPN to version 2.3.3 (this was used by me, I can’t say anything about others, but I believe that newer versions will also behave positively) and the system has been sent for another 10 years.

Source: https://habr.com/ru/post/324770/


All Articles