Certificates issued with v 0.7.0 not working when applied to Kemp Loadmaster service #517

New Issue

adam · 2025-12-29T01:26:41+01:00

adam commented

2025-12-29 01:26:41 +01:00

Originally created by @bretgiddings on GitHub (Feb 13, 2021).

Having upgraded to version 0.7.0, I am finding that any newly issued live certificates don't work when applied to virtual IPs on Kemp Loadmasters. Running s_client against the virtual IP results in

# openssl s_client -connect host.name.on.kemp:443 < /dev/null | more
write:errno=0
CONNECTED(00000003)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 99 bytes and written 637 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Using the same method to upload a certificate issued by a previous version of dehydrated (0.6.5) results in a valid certificate being returned. I suspect I may be seeing a similar issue with pushing a certificate to a Tomcat install.

If I use openssl x509 to examine the issued certificate, everything appears to be in order...

Originally created by @bretgiddings on GitHub (Feb 13, 2021). Having upgraded to version 0.7.0, I am finding that any newly issued live certificates don't work when applied to virtual IPs on Kemp Loadmasters. Running s_client against the virtual IP results in ``` # openssl s_client -connect host.name.on.kemp:443 < /dev/null | more write:errno=0 CONNECTED(00000003) --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 99 bytes and written 637 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- ``` Using the same method to upload a certificate issued by a previous version of dehydrated (0.6.5) results in a valid certificate being returned. I suspect I may be seeing a similar issue with pushing a certificate to a Tomcat install. If I use _openssl x509_ to examine the issued certificate, everything appears to be in order...

adam closed this issue

2025-12-29 01:26:41 +01:00

adam commented

2025-12-29 01:26:42 +01:00

@bretgiddings commented on GitHub (Feb 13, 2021):

Doh - found the problem by comparing output of openssl x509 - I hadn't set the KEY_ALGO in the configuration file and thus the new version used a public key type that appears not to be supported.

@bretgiddings commented on GitHub (Feb 13, 2021): Doh - found the problem by comparing output of _openssl x509_ - I hadn't set the KEY_ALGO in the configuration file and thus the new version used a public key type that appears not to be supported.

adam referenced this issue

2025-12-29 01:29:41 +01:00

[PR #517] [CLOSED] fix date in man page #856

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#517