Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
New on LowEndTalk? Please Register and read our Community Rules.

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

youandriyouandri Member

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?

  • @luckypenguin said:
    Wtf is Internet.nl?

    Seems to be the dutch government kind of reinventing mxtoolbox ;)

  • youandriyouandri Member

    @luckypenguin said:
    FreeBSD guy here. Wtf is Internet.nl?

    It's security testing tools.
    Any idea? :)

    @totally_not_banned said:

    @luckypenguin said:
    Wtf is Internet.nl?

    Seems to be the dutch government kind of reinventing mxtoolbox ;)

    Yes, testing tools. :)

  • edited May 28

    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.

  • youandriyouandri Member

    @totally_not_banned said:
    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.

  • JohnnySacJohnnySac Member

    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 postconf and doveconf to help see your settings.

  • youandriyouandri Member

    @JohnnySac said:
    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 postconf and doveconf to help see your settings.

    Thanks, that helped narrow it down a lot. :)

    I checked all active services individually:

    • SMTP STARTTLS (25)
    • Submission STARTTLS (587)
    • IMAP STARTTLS (143)
    • IMAPS (993)

    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:

    • a stale/cached result from internet.nl,
    • a false positive,
    • or that their scanner is detecting something other than the currently negotiated TLS handshake.

    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.

  • emperoremperor Member

    Remove 1.2 for a bit and test again, to narrow it down even more for false positive

  • youandriyouandri Member

    @emperor said:
    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:

    • SMTP STARTTLS (25)
    • Submission (587)
    • IMAP STARTTLS (143)
    • IMAPS (993)

    After doing that:

    • TLS 1.2 connections fail as expected
    • TLS 1.3 works normally
    • all live handshakes show SHA256 only
    • no SHA1 appears anywhere in the negotiated session

    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:

    • a false positive,
    • stale detection,
    • or some edge-case in their scanner.

    Your suggestion to isolate by protocol version was definitely the right direction.

    Thanks again.

Sign In or Register to comment.