default openssl.cnf file location used by Certificate Manager

[nagaraja]

Hello guyz,

i want to add some extension parameter for certificates rolled out by certificate manager on pf box.

I think openssl is used to make this job done, find command got several files

[21.02-RELEASE]root: find / -name "*.cnf"
/usr/local/openssl/openssl.cnf
/usr/local/share/pfSense/ssl/openssl.cnf
/etc/thoth/openssl.cnf
/etc/ssl/openssl.cnf

Which file is the default one used by system?

Thanks

[jimp]

@nagaraja said in default openssl.cnf file location used by Certificate Manager:

Which file is the default one used by system?

For what purpose? For certificates, /usr/local/share/pfSense/ssl/openssl.cnf is the stock file from pfSense but it gets copied over /etc/ssl/openssl.cnf at boot time since most utilities pull it from there.

If you want to make changes which must be in openssl.cnf for how the certificates get generated, edit /usr/local/share/pfSense/ssl/openssl.cnf and then copy it over /etc/ssl/openssl.cnf. That way they'll be active now and for future boots.

But keep a copy of the stock file in case your edits need to be reversed.

[nagaraja]

@jimp

@jimp said in default openssl.cnf file location used by Certificate Manager:

@nagaraja said in default openssl.cnf file location used by Certificate Manager:

Which file is the default one used by system?

For what purpose? For certificates, /usr/local/share/pfSense/ssl/openssl.cnf is the stock file from pfSense but it gets copied over /etc/ssl/openssl.cnf at boot time since most utilities pull it from there.

If you want to make changes which must be in openssl.cnf for how the certificates get generated, edit /usr/local/share/pfSense/ssl/openssl.cnf and then copy it over /etc/ssl/openssl.cnf. That way they'll be active now and for future boots.

But keep a copy of the stock file in case your edits need to be reversed.

Hey @jimp , thanks for your answer.

Since [ ca ] call [ CA_default ] and parameter x509_extensions = usr_cert

i added to /usr/local/share/pfSense/ssl/openssl.cnf section [ usr_cert ]

crlDistributionPoints           = URI:http://mycdp:8000/crl/distribpoint.crl

In the end, i cp /usr/local/share/pfSense/ssl/openssl.cnf /etc/ssl/openssl.cnf

I then created a CA then an Intermediate CA that issued a cert. So, i checked all three certs and i did not get any trace of my job.

What's wrong here?

[nagaraja]

@nagaraja

Does anybody able to confirm this is a common behavior?

I cannot believe i am the first one that wants to add an extension property on pfsense CA's cert

[jimp]

@nagaraja said in default openssl.cnf file location used by Certificate Manager:

I cannot believe i am the first one that wants to add an extension property on pfsense CA's cert

You may very well be -- it's not a supported process nor one that most people would expect the certificate manager on the firewall to handle.

You probably want the v3_* sections not the ones you edited.

[nagaraja]

@jimp

@jimp said in default openssl.cnf file location used by Certificate Manager:

@nagaraja said in default openssl.cnf file location used by Certificate Manager:

I cannot believe i am the first one that wants to add an extension property on pfsense CA's cert

You probably want the v3_* sections not the ones you edited.

Yes, that perfecly worked. I used [ v3_ca ] and i was able to find the url reference both on CA and Intermediate cert's property. TYVM @jimp

Just a consideration here: crlDistributionPoints should be expressed in a multiple values string because every CA generated, has the same url: in the view of CA/Sub hierarchy both crl lists should be served.

You may very well be -- it's not a supported process nor one that most people would expect the certificate manager on the firewall to handle.

Is that so strange? I had to install pfsense CA for webUI authentication and I am actually using acme for public cert generation, I have a script that securely share certs after renew.
Why not, i can have everything on the same panel. Having pfsense Certs Manager as internal root ca since it is replicated by sync ha with a decent crl manager is a resource saver and It is ready there faster than any other implementation.
Okay it's not the best in features without any automation but for a small environment to sign scripts or auth services seems to work fine (i already successfully tested it to autenticate web services or rdp client sessions with crl revocation checks)

In terms of security, if pfsense CA can be used by OpenVPN, can be generally considered satisfying i believe.

[jimp]

It's unusual because it's not intended for that role (yet, at least) -- adding functions which are useful outside of the firewall is out of scope, even if the cert manager is convenient to use.