PSA: 2.7.1, changes to OpenSSL, broken webConfigurator

[ttmcmurry]

PSA: If you upgrade to 2.7.1 and the webconfigurator no longer works, it could be an issue with both the internal CA and the cert assigned to the webconfigurator.

Symptom:

• When booting, you see "Starting webconfigurator ... failed"
• The console shows the system is ready, and the firewall works
• You are unable to reach https://<firewall>, the browser spins and eventually gives up as the url is not reachable

Fix:

• Reset the webconfigurator to HTTP

  • On the console, reset the LAN IP to the same IP; the script that performs this action will reset the webconfigurator
  • When asked to use HTTP for the webconfigurator, do so (in other words don't use HTTPS)
  • Log into the firewall with http://<firewall>

• Idenfity the issue

  • Go to Status -> System Logs
  • Identify an error entry "/rc.restart_webgui: The command '/usr/local/sbin/nginx -c /var/etc/nginx-webConfigurator.conf' returned exit code '1', the output was 'nginx: [emerg] SSL_CTX_use_certificate("/var/etc/cert.crt") failed (SSL: error:0A00018E:SSL routines::ca md too weak)'"
  • That last line indicates the CA is too weak. You must build a new CA.

• Fix the Certificate Authority (CA)

  • Go to System -> Certificates
  • Create a new Certificate Authority
  • Give it a name other than "internal-ca" - for example "new internal ca" or whatever is easily identifiable by you
  • Select Key Type "ECDSA" and curve "Prime256v1" unless you (a) know what you're doing (b) have a technical requirement to select something else
  • Use a Digest Algorithm of sha256. Your use case may allow a higher bit length, however 256 should work virtually everywhere these days
  • Leave the lifetime alone
  • Leave the common name alone
  • Specify Country/state/city/org as needed
  • Save

• Issue a new webconfigurator cert against the new authority

  • Go to the Certificates Tab
  • Click Add
  • Give it a name that is easily identifiable as the new certificate "WebC New Cert" or whatever works for you
  • Select the new CA you created
  • Select Key Type "ECDSA" and curve "Prime256v1" unless you (a) know what you're doing (b) have a technical requirement to select something else
  • Use a Digest Algorithm of sha256. Your use case may allow a higher bit length, however 256 should work virtually everywhere these days
  • Set Cert Lifetime At/Around 365 days
  • Give it a common name - this will be the URL/FQDN that identifies your firewall such as "pfsense.mynetwork.lan"
    • IMPORTANT: You may need to look at System -> General Setup -> Domain such that the new certificate's domain name matches what's set in General Setup
  • Set Cert Lifetime At/Around 365 days
  • Specify Country/state/city/org as needed
  • Save

• Set the webconfigurator back to HTTPS

  • Go to System -> Advanced
  • Select protocol HTTPS
  • Select the certificate "WebC New Cert" or whatever you named it
  • Leave everything else alone. Scroll down to the bottom and Save.
  • The screen will refresh after 20 seconds in HTTPS mode. You will receive a notice the connection is untrusted, which you should accept, then login.

This should fix the issue; as it did for me. The problem seems to stem from when the default CA was automatically generated when I installed 2.7.0 from scratch a few months ago.

If you're using certs for other services, you may wish to regenerate those against the new CA and associate the cert to those services. For example, with DNS over HTTPS.

[ttmcmurry]

After looking at this more, it seems like the last restore I did contained the CA from the builds I started backing up in 2021.

Does the pfSense upgrade script perform prechecks against the CA and Certs to determine if they support the changes made to OpenSSL? There's good written guidance about the changes, which helped in diagnosis. However, I'm unsure if the upgrade process helps to prevent issues before they occur, given the scope of the changes.

[jimp]

@ttmcmurry said in PSA: 2.7.1, changes to OpenSSL, broken webConfigurator:

Does the pfSense upgrade script perform prechecks against the CA and Certs to determine if they support the changes made to OpenSSL? There's good written guidance about the changes, which helped in diagnosis. However, I'm unsure if the upgrade process helps to prevent issues before they occur, given the scope of the changes.

There is code that checks the CA and cert for weak algorithms before allowing them to be used by nginx (among other things). It detected everything I threw at it (and it made a new cert as needed) but it's possible something is slipping past the detection code.

Rather than switching to HTTP you should just make a new self-signed GUI cert with pfSsh.php playback generateguicert since your browser probably won't let you go to HTTP in many cases thanks to HSTS.

https://docs.netgate.com/pfsense/en/latest/config/advanced-admin.html#ssl-tls-certificate

[ttmcmurry]

@jimp

Thanks, Jim.

I've replayed the upgrade issue and localized it further to the webconfigurator cert, issued against the original CA from 2021.

Signature Digest: ecdsa-with-SHA1
Key Type: ECDSA
Elliptic curve name: prime256v1

This doesn't meet the requirements as stated in 2.7.1's release notes. It didn't seem to get detected for a weak cipher.

Appreciate the link. I was using the link for troubleshooting when locked out of the firewall (link).

[jimp]

@ttmcmurry I can't remember if I tested against ECDSA+sha1 certs, it's possible the detection wasn't capable of catching those the same way.

EDIT: I added a blurb to the lockout doc about regenerating the certificate.

[ttmcmurry]

@jimp Thank you. I believe I'm solved here.