On 25/02/2023 16:36, Bo Berglund wrote:
On Thu, 23 Feb 2023 18:34:11 +0100, David Sommerseth <dazo+open...@eurephia.org>
wrote:
Yes, you can issue new certificates using *the same* private and public
keys (essentially re-using the CSR). This will issue a new certificate
with a new expiry date. Since the certificate and CA is the same, it
just works as before.
Are most files used in this context NOT stamped with an expiration date?
I.e. does only .crt files have expiration times?
That is correct. The expiration time is part of the certificate only.
In that case I would only need to handle the ca.crt for expiration, right?
Correct. Only a new CA certificate needs to be distributed, as long as
the CA private key stays the same. A CA certificate can be renewed in
similar ways as client and server certs; but it must be distributed to
all clients.
[...snip...]
Is ca.crt the only one I need to worry about?
You have 1 client/server certificate and 1 CA certificate in the
simplest setups. All of them have expiration times. Normally a CA has
between 10-20 years expiration time. Server certs typically have 2-4
years, at least in OpenVPN context. Client certs even shorter.
But YOU as the CA admin decides the policy you want for your
certificates. If you want 10 years for everyone, you can have that.
When the client ovpn files are created the content comes from these in the
easy-rsa/keys dir:
ca.crt
ta.key
clientcommonname.crt
clientcommonname.3des.key
ca.crt and clientcommonname.crt are the ones you need to beware of.
These files are also created but not used in the ovpn files:
clientcommonname.key
clientcommonname.csr
The .csr file is the Certificate Signing Request, which is kinda like an
unsigned certificate. The CA will take this request, you review the
content of the meta data and modify it if that is needed, then sign it
with the CA private key. That gives the certificate as output (.crt file).
For the .key file, I see you have two variants. .3des.key sounds like a
password protected key, while the plain .key file is unencrypted. The
former will make OpenVPN ask for a private key passphrase, the second
one will just start the OpenVPN process without asking for that
passphrase. Which of them to use in your configs depends on the
security policy you want for your VPN connection.
And and the data from the files are placed inside sections in the client ovpn
files:
<ca> ca.crt
<tls-auth> ta.key
<cert> clientcommonname.crt
<key> clientcommonname.3des.key
Question:
---------
Is any part of the ovpn files affected if I update the main ca.crt file?
No. Only the --ca option is affected.
I.e. does an ovpn file depend on having been created after the ca.crt has gotten
its expiration extended?
No.
Then I would have to recreate all of them and update the clients too, right?
You only need to do that if you replace the CA signing key (the private
CA key) and need to issue a completely new CA certificate (and don't
start playing with cross signing, and such things; that's quite a bit
more complicated). You will also need to do similar changes if the
client private key is update. That would affect only the --key and
--cert. When renewing a client certificate only the --cert needs to be
changed.
--
kind regards,
David Sommerseth
OpenVPN Inc
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users