All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Signature Hash Key Problem - FreeBSD
Hi all,
I’m running a small self-hosted mail server and I’m trying to understand whether this behavior is expected or if I’m missing something.
Environment
- FreeBSD 14 amd64
- OpenSSL 3.5.4 (base system)
- Postfix (SMTP/submission)
- Dovecot (IMAPS)
- DNSSEC + DANE enabled
- ECDSA Let’s Encrypt certificate
- IPv4 + IPv6
- TLS 1.0/1.1 disabled
Openssl : OpenSSL 3.5.4 30 Sep 2025
Lib link:
/usr/lib/libssl.so.35
/usr/lib/libcrypto.so.35
Current TLS state:
nmap --script ssl-enum-ciphers now shows only:
- CHACHA20_POLY1305
- AES-GCM
- TLS 1.2 / TLS 1.3 only
- X25519
- no CBC
- no CAMELLIA
- no 3DES
Everything negotiates correctly with SHA256+ during actual TLS sessions.
The issue:
Despite this, Internet.nl and LuxSci still complain about SHA1 signature algorithms being advertised in TLS 1.2.
Their wording is basically:
SHA1 signature algorithms are still advertised/supported for TLS 1.2.
I already added a custom OpenSSL policy in /etc/ssl/openssl.cnf:
[ssl_sect]
system_default = system_default_sect
[system_default_sect]
MinProtocol = TLSv1.2
SignatureAlgorithms = ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
But scanners still report SHA1 advertisement capability.
Questions
1. Is this simply expected behavior with OpenSSL 3.x TLS 1.2 compatibility?
2. Does OpenSSL still advertise SHA1 internally even when stronger algorithms are preferred?
3. Has anyone successfully removed SHA1 advertisement entirely on FreeBSD/OpenSSL without disabling TLS 1.2?
4. Is this more of a scanner “policy warning” rather than a practical security issue?
The server already passes:
- SPF
- DKIM
- DMARC
- DANE
- MTA-STS
- STARTTLS
- modern ciphers
- ECDSA certs
Mail flow works correctly and negotiated sessions are using SHA256+.
Just trying to understand whether this is:
- normal OpenSSL behavior
- FreeBSD-specific
- Postfix-specific
- or something actually misconfigured.
Many Thanks ![]()

Comments
FreeBSD guy here. Wtf is Internet.nl?
Seems to be the dutch government kind of reinventing mxtoolbox
It's security testing tools.
Any idea?
Yes, testing tools.
Not really much of an idea but have you tried testing against actual mxtoolbox. To be honest i would trust them more than those 2 sites but then i have also not tried selfhosting email in like 15 years at least.
I see. Thanks.
What hostname, port, and protocol mode is the scanner testing?
25 = Postfix SMTP with STARTTLS
587/465 = Postfix submission/submissions
993 = Dovecot IMAPS
143 = Dovecot IMAP STARTTLS
First, I would narrow it down to which daemon/port is advertising SHA1 because postfix and dovecot are separate TLS servers. Once you know if it's postfix or dovecot I would look to those config files first rather than openssl.cnf. Postfix can have per-service overrides in master.cf so check there also, not just main.cf. Use
postconfanddoveconfto help see your settings.Thanks, that helped narrow it down a lot.
I checked all active services individually:
All of them negotiate TLS 1.3 successfully and show SHA256-based signatures/digests only. No SHA1 appears in the live handshake output.
Port 465 is not enabled/listening on this server.
I also checked the effective Postfix and Dovecot TLS configuration (
postconf,postconf -P,doveconf -n) and I do not currently see any obvious SHA1-related TLS settings.At this point I’m starting to suspect either:
DNSSEC/DANE/MTA-STS/etc. all validate correctly now as well.
Appreciate the guidance, checking per-service instead of only openssl.cnf was definitely the right direction.
Remove 1.2 for a bit and test again, to narrow it down even more for false positive
Cool.
Thanks for the suggestion that actually helped narrow things down quite a bit.
I temporarily disabled TLS 1.2 completely on both Postfix and Dovecot and re-tested all active services:
After doing that:
Interestingly, internet.nl still reports the same STARTTLS/DANE warning, while other tools now complain that the server is “too strict” because TLS 1.2 is disabled.
But it makes scrore is 100%. Yeay.
Real-world delivery tests (Gmail, MXToolbox, DMARC reports, DKIM/SPF alignment, TLS negotiation) all look healthy though, so at this point I’m leaning toward either:
Your suggestion to isolate by protocol version was definitely the right direction.
Thanks again.