Current certs are set to expire in about a year, rather than just refresh the certs I would like to update the pki security by:
Larger key size 1024 -> 2048
Encryption sha1 -> sha256 (This seems to be fine)
From what I understand upgrading to 2048 bit keys requires a new PKI to be built to upgrade the ca.key size
What is the benefit of creating a new ca vs using a 1024-bit ca.key and create new 2048-bit client/server files? (Assuming best practice/security)
The devices (Modem's) on the network have static IP addresses and are in DMZ mode (No remote access since that would be too easy), they come back and can be updated with a local connection around once a year
The goal would be to transition all the devices over about 1 year seamlessly over to the new pki
Things I have tried:
Stacked certs: https://www.hexonet.net/blog/migrating- ... or-openvpn
Create a new PKI, stack the ca.crt from the old and new PKI's
Code: Select all
cat ca_new.crt ca_old.crt > ca.crt
Code: Select all
./easyrsa build-server-full server nopass
Code: Select all
EASYRSA_PKI=pki_old ./easyrsa import-req ./pki/requests/server.csr im
EASYRSA_PKI=pki_old ./easyrsa sign-req server im
Code: Select all
cat server.crt im.crt > server_stacked.crt
Client with old ca files works if I stack in this order "cat im.crt server.crt > server_stacked.crt"
Client with new ca files works in the other order
Client Log (Old files with server cert "cat server.crt im.crt > server_stacked.crt")
Code: Select all
2021-06-18 11:02:56 VERIFY ERROR: depth=0, error=unable to get local issuer certificate: C=AU, ST=VIC, L=MELBOURNE, O=server, CN=server, name=server, emailAddress=test@test.com.au, serial=1
2021-06-18 11:02:56 OpenSSL: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2021-06-18 11:02:56 TLS_ERROR: BIO read tls_read_plaintext error
2021-06-18 11:02:56 TLS Error: TLS object -> incoming plaintext read error
2021-06-18 11:02:56 TLS Error: TLS handshake failed
Code: Select all
port 1194
proto udp
dev tun
ca ca.crt
cert server_stack.crt
key server.key
dh dh2048.pem
mode server
tls-server
ifconfig 10.8.0.1 10.8.0.2
ifconfig-pool 10.8.20.4 10.8.40.254
ifconfig-pool-persist ipp.txt
client-config-dir ccd
client-to-client
push "route 10.8.0.0 255.255.0.0"
keepalive 10 120
cipher BF-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 4
Code: Select all
client
dev tun
proto udp
remote 192.168.254.126 1194 # Test OpenVPN VM
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
cipher BF-CBC
comp-lzo
verb 3
auth-nocache
I have also tried creating a subCA from the 1024-bit ca and using that as the new CA same method as above(Works on a windows client but not on NetComm modem's gives same error as above)
Clients never seem to know that there is a second server cert, i'm not sure why this is
Is there something else I have missed here
Multiple Instances
Also tried running 2 OpenVPN instances on separate ports but couldn't figure out how to get them working with the same subnet, don't think that is even possible
Each had a similar config with different ports and ifconfig values and using files from completely separate pki's (And different log file names)
(Required as devices have static IP's and can not be changed remotely)
If this is simply not possible, then will have to refresh the expiring certs and find a way to be able to update the devices remotely to move to fresh pki later