Still getting “A valid Root CA Certificate could not be located”

This is a report of the topic here, but I am still having this issue.

Hello,

I've been making certificates using win-acme. The web server is 4D. Validation is DNS with DreamHost.

Some SSL checkers say the certificate chain is fine and others report that a valid Root CA could not be located. Why? Geocerts is one of them.

Domain is simon4d.bel.com . Note that this is a different server entirely than bel.com, but that hasn't mattered before.

I'm creating PEM files with the win-acme tool, and 4D uses the full chain and key files. I am not modifying them. There are no settings in 4D pertaining to SSL or management of certificates.

Can anyone view the domain's certificate and tell me what's going on? If it helps, there's a blank htm file here.

SSL Labs reports:

Additional Certificates (if supplied)
Certificates provided 5 (6821 bytes)
Chain issues Incorrect order, Extra certs
2 Likes

Here https://decoder.link/sslchecker/simon4d.bel.com/443, here Hardenize: Comprehensive web site configuration test, and here (as @rg305 has already pointed out) SSL Server Test: simon4d.bel.com (Powered by Qualys SSL Labs) all are stating "Chain issues -Incorrect order, Extra certs".

1 Like

Right, but how do I resolve this? 4D has no settings or controls and the only instruction is to put the key.pem and cert.pem in the application directory.

The files are the exact PEM files from the win-acme script, just renamed. The cert is the full chain file, which is what we've used in the past. Should this not be the full chain file?

That might be the case indeed. I have no experience with 4D (nor Windows for that matter), but seeing the chain is send twice, the solution might be to use cert.pem instead of fullchain.pem: perhaps one of the two chains currently send disappears.

That said, even if one of the duplicate certs is removed, the final cert in the chain is still the ISRG Root X1 cert signed by the now expired DST Root CA X3 root certificate, i.e., the "Android compatibility chain" a.k.a. the "long chain". It might be the error does not go away even if just a single chain is send.

3 Likes

Also sound like Verifying a certificate - #5 by jsha

Perhaps choose different programs, ones that properly construct Paths and uses of Chains.

1 Like

This interested me, so I did a quick online search.

  1. Running SSL on that server requires a special plugin/library installed. Make sure it is installed.
    2- All the tutorials and info I've read talk about cert.pem having a certificate - not a chain. This makes me wonder if it can support certificates signed by intermediaries, as supporting only a leaf certificate implies the server builds it's own trust path across known intermediates/roots. This wouldn't surprise me, because this server's documentation suggests it is mostly used in contexts where a self-signed or corporate certificate would be used - not a publicly trusted one.

For stuff like this, I find the only real option is to build out a test matrix of different possible combinations in a text document, and test them all - adding detailed notes to each one you tried.

e.g.

  • Test Leaf Certificate only
  • Test Leaf Certificate + [Intermediates, ]
  • Test Leaf Certificate + [Intermediates, ] + Root

I would do this for each of the possible intermediate chains.

3 Likes

It might not support intermediates itself, but the service running behind port 443 does send them.. Twice..

4 Likes

The chain you have is:
simon4d.bel.com ▶▶ R3 ▶▶ ISRG Root X1 ▶▶ R3 ▶▶ ISRG Root X1 ▶▶ [DST Root CA X3] which looks to me like some confusion matching the intermediate vs root names.

Try setting the Preferred Chain option to ISRG Root X1 in your win-acme config and renew the cert to force the files to be rebuilt (there may be another way to regenerate the files in win-acme but I don't know it).

You may also consider just using a more common web server like IIS, nginx, caddy etc and reverse proxy that back to to your 4D site as http, if not ensure that you are always using the latest version of 4D because webservers are constantly under attack while connected to the internet.

4 Likes

This is GREAT advice, and this technique is very often used when a web server is either older or has limited support for Ciphers and/or TLS versions.

6 Likes

Possibly the 4D forum could be of assistance Web server and https - English Community - 4D Forum
and the 4D Doc Center also Web Server, Overview

4 Likes

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