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.
I ran this command:
placed www.upfront-rentals.com in chrome(131.0.6778.205 (Official Build) ) browser url on windows 10.
I get similar errors in edge, but don't seen to get these errors on my ubuntu desktop)
It produced this output:
a window popped up asking for me to select a certificate to which I want to authenticate.
the certificate status is "the issuer of this certificate could not be found"
please see attached screen shots
Well, there is something wrong with www.upfront-rentals.com: it's not sending the required intermediate certificate (but some browsers can deal with that in a few ways).
However, your screenshot is quite weird, as it's not showing the actual Let's Encrypt certificate from the www.upfront-rentals.com website!
So maybe there are 2 things not correct or the screenshot is a red herring and is just due to some antivirus software that you have installed. In any case, the screenshot does not resemble the actual website.
Are you the system operator of www.upfront-rentals.com?
Edit:
Nevermind the screenshot: that's just your browser asking for a client authentication certificate, I'm getting that too. That said, the website is not correctly configured either way.
OpenSSL is also complaining about a too small DH key, so I guess the website is probably terribly configured in total.. Unfortunately currently the SSLLabs server test is not working for me, so I can't put the site to the test.
thank you for reviewing my post and trying to help.
I understand from your reply the following (& please correct me if i'm wrong):
you confirm the error reproduces on your client machine -> its not some sort of client side error on my windows machine.
the error is caused by missing information in the certificate information provided by the web server
the " too small DH key," is a separate issue from the "the issuer of this certificate could not be found" error.
I see that the certificate information returned only includes www.upfront-rentals.com certificate,
and not the full contents of the "fullchain.pem" file generated by certbot ( which I see has 2 certificates).
I am the system operator/administrator of the server,
I see where we have "installed"/configured the web server's certificates, there is only 1 cert there,
I can try to add the "other"/second certificate and retest.
regarding the DH issue,
this is completely new to me.
I've done some reading before posting this, but have not yet managed to figure out where this should be changed/configured. Is this something that can/should be during the certs generation ( as a certbot parameter) , or is this something that should be set in the webserver's configuration, or at the os level, can you please shed some light on this?
I can confirm the server is not sending its intermediate. My Chrome didn't produce an error, but that doesn't mean the error couldn't popup. Browsers tend to cache possible intermediates, so the errors may or may not appear, seemingly randomly.
Incorrect. The certificate itself is fine. The server should however also send a second certificate, the so called intermediate certificate. And it doesn't do that.
Correct, but it tells me that the webserver in question is horribly configured with regard to the TLS cipher suits.
That would be the root cause of the not-sending-the-intermediate part of this thread.
Usually one just references the files generated by Certbot directly, if possible. That said, I've never heard of the webserver "poco", so perhaps that wasn't possible
It's not related to the certificate in any way. It's a webserver configuration, but I'm not familiar with this webserver "poco".
Other reasons why I have some doubts about the webserver configurations is that I can't connect to your webserver at all using OpenSSL. When using the "simple" command
All those 1024 bit DHE ciphers are apparently not working in my OpenSSL version due to the DH key being too small and I guess my OpenSSL doesn't like those non-forward secrecy ciphers like AES256-GCM-SHA384 also. And for some reason, ancient and insecure ciphers like DES-CBC3-SHA and TLS_RSA_WITH_RC4_128_SHA, which can be cracked on any modern house-hold computer within a few hours, are enabled too?!?
You might want to consider configuring a more "modern" or more secure webserver in front of this "Poco" webserver if you're having trouble securing "Poco". This webserver would then deal with all the TLS stuff, running your Poco only in HTTP mode, where the reverse proxy in front of Poco would only connect over localhost, which doesn't need TLS.
To be frank, it's a wonder my Chrome would even allow to connect to your website. I would have thought Google to be refusing these insecure connections. But I guess luckily for you it still connects This might not be the case in the future however, so I'd recommend to increase your TLS security.
thank you again for the quick and detailed response.
regarding the dh key size.
i've noticed certbot has an "rsa-key-size" parameter.
can you confirm that setting this to 2048 will fix the " too small DH key," error?
Usually the "Select a certificate" prompt is because the site is configured to require a Client Certificate, e.g. it wants you to authenticate yourself with your own certificate, not a server one. Usually this configuration is selected by mistake.
Yes, it very much is. Ephemeral elliptic curve DH (ECDHE) is faster en more modern compared to "classic" DH and the 256 bit keysize is fine. (Note that elliptic curve keysizes are way smaller than classical DH keys, so 256 is "bigger" than 1024 in this case.)