I download to download a copy of "pfSense 2.4.2-RELEASE-p1"

Rico

SHA256 (pfSense-netgate-memstick-2.4.2-RELEASE-p1-amd64.img.gz) = fa77c20d0d7582470cfaf1bd0ee4b64b350ef36c678d4121c5ba68385fa994e3

Is this what you are searching for?

-Rico

johnpoz

@ipguy said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":

My objective is to determine if it's feasible to "renew" the expiring CRT

Problem is if the CA is expiring - the modems copy of that CA will not be renewed.. And they will not trust the renewed cert once their copy of the CA expires.. You need to update the CA on the modem so it will trust your cert that has been renewed.

There is really no point in "renewing" the old CA.. You should just create a new one.. With a new server cert off this CA.. The problem is getting the new CA to the remote boxes.

Since your not using client certs you don't have to reissue 10k certs.. You just need the remote devices to get the new CA, so then you can issue a new server cert via this new CA. That they will trust.

One way to combat this problem, is use of multiple CAs - If your CA has a life of 10 years, this should be longer then the life of the deployed remote device.. You would as the CA and certs be it server and or client, once the CA is say over 1 year old and you are going to deploy new devices you would use a different CA for these devices as they get deployed. Now any remote device should be good for the 10 years..

The heavy lifting part is going to be getting the new CA to your 10k remote devices.

ipguy

@johnpoz

Thank you for your clear and concise answer

ipguy

@johnpoz said in I download to download a copy of "pfSense 2.4.2-RELEASE-p1":

One way to combat this problem, is use of multiple CAs - If your CA has a life of 10 years, this should be longer then the life of the deployed remote device.. You would as the CA and certs be it server and or client, once the CA is say over 1 year old and you are going to deploy new devices you would use a different CA for these devices as they get deployed. Now any remote device should be good for the 10 years..

I've explored some aspects of CAs and CRTs before, but this experience is taking me into much deeper territory.

I may be mistaken but by the looks of the "-text -noout" of the CRT currently in use on the remote modems, see below

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=MARS, ST=NYC, L=London, O=thanos/emailAddress=ca@network.thanos.com, CN=thanos-ca.network
        Validity
            Not Before: Jan 19 22:34:22 2014 GMT
            Not After : Jan 17 22:34:22 2024 GMT
        Subject: C=MARS, ST=NYC, L=London, O=thanos/emailAddress=ca@network.thanos.com, CN=thanos-ca.network
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:f4:94:86:07:f8:d7:dc:ef:ac:6a:cc:a2:c2:28:
                    ...
                    ...
                    ...
                    ...
                    0d:1c:79:e8:66:b1:bf:12:2c:50:2e:12:5b:e1:f7:
                    6a:93
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                58:E0:8B:60:1C:A9:61:92:CA:57:5C:53:8C:99:12:96:03:99:B0:91
            X509v3 MARSthority Key Identifier:
                keyid:58:E0:8B:60:1C:A9:61:92:CA:57:5C:53:8C:99:12:96:03:99:B0:91
                DirName:/C=MARS/ST=NYC/L=London/O=thanos/emailAddress=ca@network.thanos.com/CN=thanos-ca.network
                serial:00

            X509v3 Basic Constraints:
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         2f:c8:26:32:25:29:af:37:05:b2:04:cd:80:a2:9f:3d:72:84:
         ...
         ...
         ...
         ...
         30:c9:c4:a7:b6:53:7f:d4:8b:be:38:13:10:09:85:f0:af:dc:
         64:18:b2:02

The modem's are using a client CRT and a CA ?

Or am I mistaken ?

johnpoz

@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.

ipguy

@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?

johnpoz

@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 ;)

ipguy

@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

johnpoz

@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.

ipguy

@johnpoz

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

stephenw10

Mmm, there's probably quite a few people who'd benefit from your experiences with this. Let us know how it goes.

ipguy

@stephenw10

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

johnpoz

@ipguy could have to do with the serial number. If reused or issued a new one..

ipguy

@johnpoz

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