Devolutions ForumDevolutions Forum

Gateway not trusting internally issued certs on domain controllers for PAM provider LDAPS

Gateway not trusting internally issued certs on domain controllers for PAM provider LDAPS

avatar
jm2

Hello,

When attempting to configure a domain user PAM provider to use LDAPS on port 636, the testing of the connection fails, and the following error snippet is logged in gateway log file 'TLS connect: invalid peer certificate: BadSignature'

Prior to Hub/Cloud v2026.1.103, setting the protocol to LDAP and using port 636 resulted in a successful test connection, but not since.

This may impact the ability to change account passwords via PAM, as Active Directory mandates that activity be performed via an encrypted connection, typically LDAPS on port 636.

Please let me know if any additional information is required.

Thanks
Joe

All Comments (2)

avatar
Michel Audi

Hi Joe,

Thank you for the details, speaking about error TLS connect: invalid peer certificate: BadSignature indicates that the Gateway is rejecting the certificate presented by the domain controller during the LDAPS TLS handshake. In this configuration, the LDAPS connection is initiated from the Devolutions Gateway / Hub Services side, so the issuing CA for the domain controller certificate must be trusted by that machine.

A few things to validate on the Gateway / Hub Services host:

  1. Make sure the internal Root CA, and any Intermediate CA if applicable, are installed in the machine trust store, not only the current user store:
    • Windows: Certificates (Local Computer) > Trusted Root Certification Authorities
    • Linux: add the CA certificate under /usr/local/share/ca-certificates/... and run sudo update-ca-certificates
  2. Confirm that the domain controller certificate is valid for LDAPS:
    • It includes Server Authentication EKU.
    • The CN or SAN contains the FQDN used in the PAM provider’s Domain controller field.
    • The certificate has a private key on the DC.
    • The chain builds to a CA trusted by the Gateway / Hub Services host.
  3. Confirm the provider is configured explicitly as:
    • Protocol: LDAPS
    • Port: 636


Using LDAP with port 636 may have worked previously due to looser handling, but the expected configuration is now to select LDAPS when using port 636.

  1. From the Gateway / Hub Services machine, test the certificate chain directly, for example:

openssl s_client -connect dc01.example.com:636 -showcertsIf the chain, hostname, or signature validation fails there, the PAM provider test will fail as well.
Could you also confirm whether the Devolutions Gateway / Hub Services machine is domain-joined? If it is not domain-joined, it will not automatically trust your AD CS internal CA, so the root/intermediate CA certificates must be imported manually.

If everything above validates correctly and the issue only started after 2026.1.103, please send us:

  • the Gateway logs around the failed test,
  • the OS where Gateway
  • whether the Gateway host is domain-joined,
  • and the sanitized output of the LDAPS certificate chain test.

We can then determine whether this is an environment trust-chain issue or a regression in the latest validation path.

best regards,

Michel Audi

avatar
jm2

Hi Michel,

The gateway server is domain joined, and ldp.exe successfully connects to domain controller using SSL, which infers there is no certificate trust/chain issue from the OS perspective.

However, openssl reported an error saying 'EE certificate key too weak', so I upgraded the cert on the domain controller from a 1024 to 2048 public key, and then Hub/Cloud was able to connect successfully via LDAPS.

I guess the question becomes, does gateway have a prerequisite of => 2048 bit keys on domain controllers for LDAPS, and/or is there a way to relax this requirement to support legacy 1024bit keys?


Thanks
Joe