I download to download a copy of "pfSense 2.4.2-RELEASE-p1"
-
@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
CA:TRUE
That is your CA cert.. Thought you said you were only using username:password to auth.. And not client certs..
So on your openvpn server setup.. What are you using?
I use only cert ssl/tls setting.
I you are using only "user auth" then there is no client cert.
If you are using the last one then you need both a client cert and user auth to connect..
If your not using client certs, then the only thing that needs to be deployed is the new CA cert to your remote devices. If you were using client certs you would need to deploy both the CA and the client cert.. Which would mean you would need to generate 10k new certs..
edit: One method to combat this problem is multiple instances of your openvpn server where every year say or every 2 you fire up a new instance of CA and server cert good for 10 years, even if using clients issued off this CA.. So new clients or replaced remote clients get the latest instance.. And should have a life of 9 to 10 years..
Part of the reason I brought up if was working with 10k remote devices not sure if would use openvpn on pfsense. There is going to be some lifting involved in making sure you don't run into a situation like your in where you have 10k devices that in 6 months are all going to be expired. If you plan for it - its not something that can't be handled.. But seems you fell into a mess.. Sorry but off the top of my head I can really think of a easy solution. You prob should just bite the bullet and figure out how you can get get the new CA deployed to all your devices..
Do you have control or access to these remote devices - or do only the local people have access. If you issue a new CA, and communicate to your remote sites they need to make the change on their client and point to the new instance running the new CA and server cert.. I would do that now, so they have 6 months to make the move.
-
@johnpoz said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
I you are using only "user auth" then there is no client cert.
We are using "User Auth"
This experience has truly opened my eyes, as I realized that my understanding of (CAs) and (CRTs) was not as solid as I initially thought.
Let me make sure I understand correctly: I should first deploy a new (CA) to the remote appliances, and after that, proceed with renewing the (CRT) on the server
Am i correct?
-
@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
proceed with renewing the (CRT) on the server
You wouldn't be able to "renew" if you create a new CA.. Either way your going to have to get either an update CA (renewed) or New one.. With a new one you can use say ecdsa vs old rsa..
Since you have to get either new or updated CA cert to the remote clients either way. You prob best creating a new CA, and issue a new server cert so you can make sure you using current best practice, etc. Where you can move to new ecdsa vs rsa..
Even if you just renew the CA and then renew the server cert - the CA still has to be gotten to the remotes..
Look on the bright side, you don't have to generate 10k new client certs ;)
-
@johnpoz said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
Look on the bright side, you don't have to generate 10k new client certs ;)
Getting an additional, but new, CA on the modems is less risky than trying to replace/ renew the existing one
Thanks for your tireless input, it's greatly appreciated
-
@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":
Getting an additional, but new, CA on the modems is less risky than trying to replace/ renew the existing one
I would think so - because if doesn't work they should just be able to use the old one and connect to the old instance until you work out what is wrong.
-
I am confident that implementing an additional "new" CA on the remote devices will enable me to continue using the existing old CA along with the current old server CRT.
Moreover, it will provide me with the flexibility to update a DNS A record, directing the devices to the new server with the new CRT.
As you said
-
Mmm, there's probably quite a few people who'd benefit from your experiences with this. Let us know how it goes.
-
I have encountered a puzzling question that I would like to address.
On a seperate note, with my previous tests
Upon migrating the CA and CRT from the old pfsense 2.4.2 to 2.5, I discovered that renewing the server CRT through the GUI resulted in the failure of the remote devices (specifically, a test device) to establish a connection.
Considering that we still have 6 months before the CA and CRT expire, I had anticipated that the device would not encounter any issues related to the CRT renewal. However, the unexpected happened and the test device rejects the new CRT and fails to connect
-
@ipguy could have to do with the serial number. If reused or issued a new one..
-
The default was to use the same serial number which is what, I think, I left selected
Will test that again just because, why not
Puzzling
