Certificate chain incomplete

#1

First, thanks for the app. It was quite helpful.

I created my cert and got it installed. To check it, i immediately went to Qualys SSL Labs to check to make sure everything was OK.

It reported that “This server’s certificate chain is incomplete.” A little more testing showed that it does seem to be incomplete.

What did I do wrong? I can’t find any option to include the cert chain.
How can I fix this?

Thanks!

#2

You might need to include what your environment looks like and what steps you took that might have been off the beaten path.

There should be three certificates in the chain.
1. [Your site]
2. Let’s Encrypt Authority X3
3. DST Root CA X3

I once did a custom implementation where I used OpenSSL to extract the certs and keys from a PFX, but forgot to tell it to include the chain… so the client knew the immediate cert, but didn’t know how to connect it to a CA that it trusted.

Once I realized that mistake and found the switch to use, the cert resolved correctly.

#3

I just went through the Certify interface. I didn’t make any strange selections and can’t see what different option I could have chosen.

Anybody else?

#4

Hi, this is not common which suggests something is not quite right. Is your server completely up to date with the latest windows updates? Certain certificates are maintained as a trusted list my microsoft, and it’s only in special cases that you would manually import new ones. It may also be that the server needs a reboot to clear cached certificate chains.

If it still isn’t right after updating and rebooting, try importing the certificate again using: Show Advanced Options > Other Options > Re-apply Certificate to Bindings, which will re-import the PFX and update the bindings again.

If that still doesn’t work try requesting the certificate again (although I don’t expect any difference from this).

#5

I just created a second certificate and everything worked fine this time, including the intermediate certificate. Why? I have no idea.

For the record:

  • Windows Updates: yes, of course, Windows Server 2016
  • This is one of a few servers responding to www.mydomain.com, but using DNS for authentication probably gets around this problem.
  • The first time I did it, the DNS authentication information was presented to me in a grayed out side panel where copying for pasting was not permitted. That was…confusing. I hope you find a better way to present that to people.
  • If I can help you troubleshoot something here, let me know.

But thanks everybody!

#6

@rebel glad it’s working OK now, occasionally glitches do happen at the operating system level that we can’t control and if that happens then restarting IIS or windows can be the solution, however such things are very rare.

Regarding multi-server hosting of a site, yes DNS authentication would be required currently. We’re looking at a way to combine CCS with shared challenge request config so that any server looking at a shared UNC path could answer http challenges for a given domain.

#7

To follow up, in putting this wildcard cert on other servers, one of the other servers had the same problem. I believe restarting the application pool (or something else) did the job.

1 Like
#8

I’m currently getting the same error and can’t figure out how to resolve it. I’ve requested a new cert 4 additional times and it has not corrected it yet. I also updated my server from windows 2008 r2 to server 2016 just so I could get SNI enabled and request a separate cert just for the single domain that I actually care about as I have several others hosted on the same machine.

Any further suggestions?

#9

@skindogz Hi, can you please email support at certifytheweb.com with the log file for your certificate requests, and an example domain that exhibits this problem. If you are testing with only one browser people try another browser to confirm it’s not a caching issues. I assume there is no load balancing or proxy servers in front of the server.

#10

p.s. please also confirm that your server Computer Certificate store has a certificate installed in Third-Party Root Certification Authorities > Certificates > DST Root CA X3 - without that (which is automatically provided/updated by windows) things wouldn’t go well.

#11

See also: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn265983(v%3Dws.11)

#12

I also just had this issue. This is my theory for what happened. LetsEncrypt recently (within a year or so?) retired its “Let’sEncrypt Authority X3” intermediate certificate and now uses an “R3” certificate.. For some reason, it doesn’t seem like Windows Server 2016 Essentials has this intermediate certificate. Not sure if CertifyTheWeb would add this certificate or if it should come from Windows Updates, but either way it doesn’t seem like it made it in my case.

My guess is that when creating a New Certificate CertifyTheWeb might install the necessary intermediate certificates, resulting in the issue being resolved for some folks when they create a new certificate request, whereas during renewal requests this doesn’t happen. But it’s just a guess. Here’s how I solved the issue:

  • First make sure you have the Root Certificate reported by your certificate path in your browser, per @webprofusion.
  • Download the relevant Intermediate Certificate “R3” (or whatever your certificate reports when you open a browser and view the certificate path) from Let’sEncrypt’s website (or your chosen provider).
  • On Windows, open System Certificates -> Intermediate Certification Authorities -> right click Certificates -> Import. If you download the PEM, rename the extension to .cer or .crt (it’s the same), and choose that file when importing.
  • Request a new certificate from your provider
  • Restart your IIS site or app pool if necessary
#13

The PFX we produce by default will include the intermediate. If you then use the certificate as part of an export or custom scripting then to make it work with other services you also have to ensure you export the full chain. This issue is not relevant to IIS users using the default deployment method.