My domain is:
I ran this command:
openssl s_client -connect v2-v3bridge.dart.masterdocs.com.au:443
It produced this output:
0 s:CN = *.dart.masterdocs.com.au
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O= Digital Signature Trust Co., CN = DST Root CA X3
The operating system my web server runs on is (include version): Ubuntu 18.04.1 LTS
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, or provide the name and version of the control panel): No
The version of my client is (e.g. output of
certbot --version or
certbot-auto --version if you're using Certbot): 1.29.0
I've encountered a frustrating issue with my SSL implementation due to what may be related to Let's Encrypts CA-X3 certificate expiration.
Please be forewarned that I am a developer with limited understanding of SSL.
Testing the request in Postman is giving me the error:
SSL Error: Unable to get local issuer certificate
I get the same response from a curl command.
Could somebody please help me diagnose and rectify this problem? I'm unsure where/how to diagnose and fix the issue. I am stepping into a role where the previous person has (I believe) made some unorthodox changes in an attempt to fix this issue and I am fairly lost.
OS: Ubuntu 18.04.4 LTS
Hi @foxhill22, and welcome to the LE community forum
This is very outdated:
Please show the files being used to serve that cert.
Thank you for the welcome
Sorry but I don't know which files I should be posting?
Review your notes (or installation instructions) and show the file used [names/locations only] to enable TLS/HTTPS.
Ah that's the problem I'm afraid - there are no notes or installation instructions. I'm taking over a role where everything is unknown and the previous person is not available for contact.
As a developer, this is a bit out of my area of expertise.
I'm not sure if this is relevant, but when I access the site through a browser the certificate shows as OK:
But running a CURL command or using Postman gives me the "unable to get local issuer certificate" message.
That can happen. Browsers work very hard to make a valid chain to adapt to poorly functioning servers. curl just works with what it is given.
Right now I cannot see your domain on any port. Have you taken it down? It looks like a firewall is blocking all ports. Is your firewall blocking access to US IP addresses?
Sorry it should be: v2-v3bridge.dart.masterdocs.com.au. I have updated the OP.
PORT STATE SERVICE
22/tcp filtered ssh
80/tcp filtered http
443/tcp filtered https
Curses! Yes I think it's limited to Australia and NZ.
Just puts more burden on you.
Your Postman server is not sending a current "chain". It sends a valid leaf (the end or server cert) but there should not be an R3/X3 right after that. This is not related to the X3 expiration in Sept. The chain you send was obsoleted early 2021.
It's nicer when we can connect and look at things directly.
But, may not be needed here. Do you know what acme client was used to get your certs? I see they are wildcard so use a DNS challenge - if that helps at all.
@foxhill22 I'll be stepping away for a bit but I found this in the Postman docs.
If you were using certbot the name of the file used in that postman screen would be
fullchain.pem. Other ACME clients may give it a different name but the file, by default, has 3 certs in it. Just
type it out and look for the cert headers. There is also a "short chain" with just 2 certs but you would have to request that so probably have not.
The postman screen also shows a pfx but I'm not sure what that is for given it asks for a pem file.
I believe that certbot was used to get the certificates.
Would posting my fullchain.pem file help?
No, not really. If it's dated recently I'm sure it's fine. Is that the file named in your Postman screen? Does your config screen look like the one in the postman docs I linked to?
@foxhill22 Oops. I thought we were connecting to postman but I see that nginx is responding on port 443. (I used a VPN to bounce from Sydney)
So, check your
ssl_certificate in nginx for this server block names the fullchain.pem file and not, well, something else
EDIT: Is this the nginx version I should expect for that domain?
HTTP/1.1 400 Bad Request
Date: Fri, 15 Jul 2022 03:39:15 GMT
I wish I knew mate, I wish I knew.
My understanding of the environment is:
It's a very simple nodejs application running in a docker container on an azure VM. I've not heard a whisper about nginx. Another application attempts to contact it from outside the firewall and gets the error.
The vague certificate renewal instructions I have include a step to configure a fortigate firewall with the newly created fullchain and privkey files (which I have done) as part of it's SSL inspection feature.
It's confusing because I have no idea where to start...
ETA: I am confused as to where the outdated certificate chain is being "served" from.
Does it use port 443 for this connection?
I am confident your Fortigate is the one "serving" the faulty cert chain.
I have no personal experience with Fortigate. But, their docs show the "SSL Inspection" feature here. The client (browser, app, ...) submits a request and Fortigate terminates the SSL connection to the client with the cert you install there. It then inspects the request and re-encrypts it to send to your server. Reversing this process returns the result to the client.
It's possible they use nginx internally and perhaps that is the reason I saw those headers for one of my test requests. Just a guess. Some of my other test requests looked like they came from a firewall or other appliance which again points to Fortigate.
I did not study the Fortigate docs as to how to configure this. I'll leave that to you or perhaps another volunteer here might know.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.