SSL checker Certificat chain incomplete

Help
1

My domain is: schmiedmann.dk

The certificate is a SAN certificate.

I ran this command: openssl s_client -connect schmiedmann.dk:443 -showcerts from a Debian machine with openssl 1.1.1w which failed with error Verify return code: 21 (unable to verify the first certificate)

Same command on a Ubuntu client with openssl 3 returns that everything is ok, it returns both the leaf and the intermediate, but from what I understand that doesn't necessarily mean that it actually got the intermediate certificate from the server response.

www.ssllabs.com also reports that the certificate chain is incomplete.

ChatGPT and online search suggestions point to wrong order of the certificate but I just did a CAT cert.fullchain cert.key > cert.pem and then it worked when browsing the site. So I just assumed everything was fine. Other suggestions also points to that the CA store on the client needed to be updated and I did that without luck.

I also called another domain from the Debian machine that had a Let's Encrypt certificate, it was mentioned in another community post, which had similar issues post Chain incomplete since feb 8 2024 The reason here was because his automation was removing the intermediate certificate, it is not the case here I use the fullchain + key. But that certificate adm-oldenhage.nl is validating perfectly on www.ssllabs.com and also when calling openssl s_client -connect adm-oldenhage.nl:443 -showcerts from the Debian client that can't validate my certificate.

I have also tested the certificate from the same Debian client that failed, directly against one of the domains that are in the certificate, but that is hosted directly on the IIS so avoiding the haproxy and IIS is serving the certificate. That failed with the the same error so doesn't look like the issue is the haproxy setup or even the PEM i created. The certificate on IIS has been deployed by Certify the web and the domain works well when I browse it.

I have also tried to request new certificates, but still with the same issue.

The issue is that a supplier needs to access a API on that domain and they can't because the certificate validation fails.

My web server is haproxy on Ubuntu Linux + IIS on Windows.

The operating system my web server runs on is (include version):Ubuntu 24.04 and Windows server 2022

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site: No but Certify the web to manage my certificates.

The version of my client is I use Certify the web 6.1.9.0 it transfers the certificate files to haproxy using SSH, i also clean up the certificates so it only contains LF and not CRLF (windows)

2

I am not expert at haproxy or IIS so perhaps another volunteer with more experience with offer help. @webprofusion might address the Certify / IIS aspect.

I am just posting to confirm your server definitely sends only the Leaf and not the matching Intermediate. openssl s_client shows only the leaf and another good test site is: SSL Checker

Browsers may sometimes work without the Intermediate if it can resolve the verification using items from its own cache. They are not the best for testing chain problems.

Does haproxy terminate the TLS (HTTPS) connection on port 443?

From my own Ubuntu 22 using openssl 3 I only see the Leaf. And, while browsers may be able to "fix" a faulty chain openssl does not.

Could that test have connected to haproxy or IIS in a way different than from the public internet?

1 Like
4

Thank you for replying!

The Ubuntu 24.04 i tested from was from our company network which should be seen as a machine from the public internet so no VPN to the haproxy IIS, but I'll check from another client tonight.

That said the Debian machine that failed the the openssl test from, are hosted on the same network as the IIS but not the haproxy and it hits the haproxy.

The only thing that might be an issue and which is hard for me to test (as I can't just remove one of them :slight_smile: ) is that the haproxy point to a folder that contains 2 certificates one is the Let Encrypt SAN certificate containing various .schmiedmann. certificates and another from Sectigo for schmiedmann.com *.schmiedmann.com

The domains in the two certificates do not overlap so it should be fine.

Also the leaf the gets returned when querying schmiedmann.dk is the correct one so haproxy should not be confused here.

The schmiedmann.com certificate is by the way rated a A in a sslchecker and is served via the haproxy the same way as the *.schmiedmann.dk certificate.

But if you get the same result with only the leaf from your Ubuntu I must be doing something wrong.

Any suggestions would be appreciated.

5

Thank you I understand I have been trying al kinds of ways to combine the files i get via Certify the web.

So I get a fullchain file via Certify the web that contains my certificate and the intermediate in one file I combine that with the private key also from Certify the web using CAT and then clean up the Windows CRLF so its only LF.

There a no extra line brakes other weird charterers, it is in UTF8 format but so is the *.schmiedmann.com certificate which comes from Sectigo and it validates ok.

The structure is straight forward..

-----BEGIN CERTIFICATE-----
Leaf for yourdomain
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate (R3 or R13)
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
Your private key
-----END PRIVATE KEY-----

6

Why are you concatenating the private key with the certificate chain? The thing you should be serving is fullchain.pem, as provided by CertifyTheWeb, verbatim.

4 Likes
7

It's needed for haproxy SSL offloading says so in the documentation HAProxy SSL Termination (Offloading) in 5 Simple Steps

1 Like
8

HI, I can answer questions about Certify The Web but can't help much with HA Proxy.

From what I gather of the thread so far you've got a valid cert from the app and you've used it to export some of the certificate components for use in HA Proxy. If you are also applying this cert automatically to IIS locally the full chain will be correct as served by that server. It would be very hard to do otherwise.

There are a number of export options in the deployment tasks feature of the app, the Deploy to Generic Server task will give you the most common components ready for use in nginx, Apache etc but if you need specific PEM format bundles you should check out the Export Certificate task because it has several more options for combined bundles:

image
image730×681 15 KB

The most common reason for a server (which is not IIS in this case) only serving the leaf certificate is that you've accidentally only given it the leaf certificate file instead of the fullchain.pem. You also need to restart/reload your haproxy process after you have updated the certificate files.

Correct me if there is anything I haven't understood.

2 Likes
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.