pfSense

I have pfSense 2.6.0-RELEASE (amd64) Community Edition.

Description:¶

When renewing a ECDSA certificate, the Signature Digest algorithm go from ecdsa-with-SHA512 to ecdsa-with-SHA1.

Steps to reproduce:¶

1. Create a fresh CA cert with ECDSA / secp521r1 / SHA512
2. Once created, the "More information" button shows Signature Digest: ecdsa-with-SHA512 as expected
3. In the renew prompt, the page shows current digest ecdsa-with-SHA512. The option Enforce strict security parameters is unchecked
4. After renewal, the signature digest becomes ecdsa-with-SHA1

Comparable experience of another user on the web:¶

[[https://www.reddit.com/r/PFSENSE/comments/oc6stn/ecdsa_cert_renew_digest_algorithm_gets_reset_to/]]

The user had pfSense 2.5.1-RELEASE and he also used SHA512. But he used secp384e1. In case the post got deleted, here's what it says:

Subject:
ECDSA Cert renew digest algorithm gets reset to SHA1

Post:
On 2.5.1-RELEASE

Lets say I create a CA cert with ECDSA / secp384e1 / SHA512

the cert item "More information" button shows " Signature Digest: ecdsa-with-SHA512 " as expected

then I'm going to renew it, the page shows current digest ecdsa-with-SHA512 and curve secp384r1 
along with suggested minimums for "Strict Security" being SHA-256 or stronger / prime256v1 and that current properties would not be changed if "Strict Security" is applied

But then, after renewal, regardless if "Strict Security" is checked, signature digest becomes ecdsa-with-SHA1

and if I try to renew the latter again, the Strict Security suggestion box says ecdsa-with-SHA1 and would not change to sha256 as per the minimum

I tried changing default_md = sha512 in /etc/ssl/openssl.cnf, but that did not affect the result (the config does work for changing CA pathlen for example though, would be nice to have that in the cert creation form)

RSA certs seem to be able to keep their original digest after renewal, and an original SHA1 cert is upgraded to SHA256 with strict security, but SHA224 is not despite the 256 minimum

This looks weird to me, but I'm no certificate guru, so is this an expected behavior?

Comment from initial poster:
after taking a look at the code, here's what's up:

    upgrades to SHA256: they don't actually check what kind of hash length is used, there's a hardcoded blacklist of signature digests, such as "RSA-SHA1" (which got detected in my tests above), but SHA224 isn't there and neither is ecdsa-with-SHA<256 so either the blanket warning about <=SHA256 is wrong and should be displayed only with RSA (or whatever the right conditions are) OR their blacklist is not in sync with their own warnings/recommendations

    ECDSA reset to SHA1: they get the current digest name string as is ("ecdsa-with-SHAXXX"), and pass it to relevant php/openssl functions, sounds good, but those functions expect a value from the list returned by openssl_get_md_methods(), which, on my instance, does not return anything with "ecdsa*" (that being said, neither does openssl list -digest-algorithms), so I guess it defaults to SHA1. Funnily enough passing any other value from the list with desired hash length, such as "RSA-SHA256" or "sha512", would result in "ecdsa-with-SHA256" and "ecdsa-with-SHA512" respectively, so I guess it's smart enough to figure out the hash method even when mixed with other stuff, but it has to be a known string value