Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:davewillsinc.com
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
Sorry, just trying to figure out how to use this site. The first post is not sufficient.
My domain is hosted by another company. The certificate for my domain says it is issued by R3. I am trying to connect over SSL from an IoT device to my site, but I get the error in the subject line.
I have successfully done this for Gmail, Google Maps API, as well as another 3rd party API. So I know the firmware in my IoT works fine. And I have previously had this same error with the 3rd party where their certificate was issued by GoDaddy and to make it work I had to add another certificate from GoDaddy.
I'm hoping that all I need to do is add an R3 certificate, but honestly this is really way beyond my expertise.
When you say "add another certificate", do you mean you added a root into your IoT device's configuration? If your device doesn't trust Let's Encrypt's root CA, you might have to add it.
How you do that is device-specific. Let's Encrypt has two roots right now, named X1 and X2. You can get a copy from Chains of Trust - Let's Encrypt but what you need will depend on the device.
If you're concerned it's a problem with the website's configuration, check with SSL Server Test (Powered by Qualys SSL Labs) and make sure there's no "Chain Issues" that say "Incomplete"
Wow! Very helpful. Second part first: I went to the SSL Server Test and there was the certificate from my site and only one other certificate, R3, which my site certificate references. That test does not indicate incomplete chain issues.
First part: I went to the Chains of Trust and downloaded both certificates in .der format. I tried loading these, but my IoT didn't like those. All my other certificates are .cer, so I converted these (on-line), but still could not load them.
Thanks again for giving me something to think about. Very helpful and appreciated.
Unfortunately the .cer file format can be ambiguous and will either be DER or PEM (which is itself just base64 encoded DER, with a header and footer added).
Any further help is going to require more information about what the IoT device is.
Hmmm... I don't understand why my .cer files work for Gmail, Google Maps API and a 3rd party company's server but not for my site unless it's a bad or missing certification file.
I'm using a Microchip SAMW25 based system which has an ARM Cortex M0 plus a WiFi module that does all the WiFi communications to my router then to the web. The interface to the WiFi module includes socket management and send/receive to the web. I don't have much knowledge about what's inside the WiFi module. I just use its API to do what I need, including opening an SSL socket. There is a separate debug port into that module where I get WiFi status (not debug from my ARM firmware). That's where I get the x.509 root missing error.
The certificate files are downloaded to the WiFi module using a boilerplate batch file which talks directly to the WiFI module. This process is not part of the remaining ARM code.
When your IoT device makes a request to your server. Your server will present it's own certificate signed by R3 which in turned is signed by ISRG Root X1 (self signed). If your IoT device (or more accurately the software stack that's making the TLS connection to your server) doesn't know ISRG Root X1 (self signed) then it won't trust your server certificate.
There are two versions of ISRG Root X1 and the older style one is signed by DST Root CA X3. Your Iot device might know this one and need to the other one.
The other part that's important is that your server doesn't just present it's own certificate, it will also include the intermediate R3 signed by ISRG Root X1 (so that your IoT device only has to know/trust ISRG Root X1 and not the intermediate as well). A common server setup mistake is to only reference your own cert instead of the "full chain" file.
Thanks webprofusion. And thanks to all who are helping!
I can't get the ISRG Root X1 certificate to load.
The SSL Server test for my domain does not indicate that the cert chain is incomplete. I can load multiple certs into my IoT (with some limits in numbers).
I installed DST Root CA X3 but it didn't fix my problem.
orangepizza talks about R3 retiring. That shouldn't be a big issue for me. How do I stay on top of when the certs retire? Here?
The API Announcements category on this forum is indeed the best place to keep up-to-date on any changes. Intermediates are replaced approximately annually going forward, so this should be a routine operation.
Figuring out how to get the ISRG Root X1 certificate to load does seem like it's going to fix your problems. Do you have any documentation about what they expect, or any information about why you can't include it in your firmware?
As you probably guessed, I've been searching every possible term I could find, using all the help I've gotten here. I bumped across a post that suggested looking at internet properties in Win10. And of course, I can get what I want from a browser. So digging into that, I found the Win10 cert repository and in there were both ISRG Root X1 and DST Root CA X3. Simple to copy those and install into my IoT.
And then when I sent a message from my IoT to my domain, I got a reply. Not what I wanted, but a reply is good.
Just one thing. First, to answer mcpherrinm, I don't have visibility into what the WiFi module is doing other than some debug statements. So there's no way of determining why it complained about the certs I found elsewhere. But when I connected, the WiFI module gave this debug output:
Thanks for the input Bruce5051. I've searched the entire code source on the ARM side and there is nothing. So I believe the TLS code is entirely within the WiFi module. In which case I'm stuck with it unless Microchip does an update of that firmware.
Of course if this is a serious problem, I could ask Microchip to do that.
TLS has "alert" messages that aren't part of the data being transmitted.
It looks like it's getting a CLOSE_NOTIFY alert, which is a normal "hey, I'm closing this connection now" alert. I'm not sure why it says "WARN" there, but nothing in that debug path looks abnormal.
This root has expired and should not be used. Depending on the software used it may or may not be used at all and in some situations it has also led to erroneous behaviour.
The cross-sign which would lead to the DST Root CA X3 root also expires later this year, so any chain using it would start to fail from that moment on.
Best is to use ISRG Root X1 and ISRG Root X2 only at this time.
And thanks to all who are helping!