The issuer of this certificate could not be found

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:
www.upfront-rentals.com

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

My web server is (include version): poco

The operating system my web server runs on is (include version):
ubuntu, if not mistaken its v22

My hosting provider, if applicable, is:

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):

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.

1 Like

dear Osiris,

thank you for reviewing my post and trying to help.

I understand from your reply the following (& please correct me if i'm wrong):

  1. you confirm the error reproduces on your client machine -> its not some sort of client side error on my windows machine.
  2. the error is caused by missing information in the certificate information provided by the web server
  3. 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?

thanks,
Omer.

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 :man_shrugging:t2:

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

openssl s_client -connect www.upfront-rentals.com:443

I'm getting the

406793847A7F0000:error:0A00018A:SSL routines:tls_process_ske_dhe:dh key too small:../openssl-3.3.2/ssl/statem/statem_clnt.c:2314

error.

It tried to connect using TLS version 1.2. However, if I force TLS version 1.0 or 1.1, OpenSSL says:

40271458BD7F0000:error:0A0000BF:SSL routines:tls_setup_handshake:no protocols available:../openssl-3.3.2/ssl/statem/statem_lib.c:153

and it doesn't even try to make the connection.

Running sslscan (due SSLLabs not functioning currently), I get the followint ciphers:

Preferred TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 1024 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 1024 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA256         DHE 1024 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA256         DHE 1024 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA            DHE 1024 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 1024 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA            DHE 1024 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 1024 bits
Accepted  TLSv1.2  112 bits  DHE-RSA-DES-CBC3-SHA          DHE 1024 bits
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384            
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256            
Accepted  TLSv1.2  256 bits  AES256-SHA256                
Accepted  TLSv1.2  128 bits  AES128-SHA256                
Accepted  TLSv1.2  256 bits  AES256-SHA                   
Accepted  TLSv1.2  256 bits  CAMELLIA256-SHA              
Accepted  TLSv1.2  128 bits  AES128-SHA                   
Accepted  TLSv1.2  128 bits  CAMELLIA128-SHA              
Accepted  TLSv1.2  112 bits  DES-CBC3-SHA                 
Accepted  TLSv1.2  128 bits  TLS_RSA_WITH_RC4_128_SHA     
Accepted  TLSv1.2  128 bits  TLS_RSA_WITH_SEED_CBC_SHA    
Accepted  TLSv1.2  128 bits  TLS_DHE_RSA_WITH_SEED_CBC_SHA
Preferred TLSv1.1  256 bits  DHE-RSA-AES256-SHA            DHE 1024 bits
Accepted  TLSv1.1  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 1024 bits
Accepted  TLSv1.1  128 bits  DHE-RSA-AES128-SHA            DHE 1024 bits
Accepted  TLSv1.1  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 1024 bits
Accepted  TLSv1.1  112 bits  DHE-RSA-DES-CBC3-SHA          DHE 1024 bits
Accepted  TLSv1.1  256 bits  AES256-SHA                   
Accepted  TLSv1.1  256 bits  CAMELLIA256-SHA              
Accepted  TLSv1.1  128 bits  AES128-SHA                   
Accepted  TLSv1.1  128 bits  CAMELLIA128-SHA              
Accepted  TLSv1.1  112 bits  DES-CBC3-SHA                 
Accepted  TLSv1.1  128 bits  TLS_RSA_WITH_RC4_128_SHA     
Accepted  TLSv1.1  128 bits  TLS_RSA_WITH_SEED_CBC_SHA    
Accepted  TLSv1.1  128 bits  TLS_DHE_RSA_WITH_SEED_CBC_SHA
Preferred TLSv1.0  256 bits  DHE-RSA-AES256-SHA            DHE 1024 bits
Accepted  TLSv1.0  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 1024 bits
Accepted  TLSv1.0  128 bits  DHE-RSA-AES128-SHA            DHE 1024 bits
Accepted  TLSv1.0  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 1024 bits
Accepted  TLSv1.0  112 bits  DHE-RSA-DES-CBC3-SHA          DHE 1024 bits
Accepted  TLSv1.0  256 bits  AES256-SHA                   
Accepted  TLSv1.0  256 bits  CAMELLIA256-SHA              
Accepted  TLSv1.0  128 bits  AES128-SHA                   
Accepted  TLSv1.0  128 bits  CAMELLIA128-SHA              
Accepted  TLSv1.0  112 bits  DES-CBC3-SHA                 
Accepted  TLSv1.0  128 bits  TLS_RSA_WITH_RC4_128_SHA     
Accepted  TLSv1.0  128 bits  TLS_RSA_WITH_SEED_CBC_SHA    
Accepted  TLSv1.0  128 bits  TLS_DHE_RSA_WITH_SEED_CBC_SHA

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 :slight_smile: This might not be the case in the future however, so I'd recommend to increase your TLS security.

2 Likes

Dear Osiris,

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?

No, it does not. As I already said:

And that Certbot options relates to the RSA key size used for the certificate.

The RSA asymmetric cryptography algorithm and the Diffie-Hellman key exchange algorithm are completely different things.

Sounds like you might want to leave configuring HTTPS webservers to someone else with more experience and/or knowledge of these matters.

2 Likes

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.

2 Likes

Hi @omerbrandis,

It seems the server is not serving up the intermediate certificates, as shown here https://decoder.link/sslchecker/www.upfront-rentals.com/443 and is this issued certificate crt.sh | 15299096662

However the issuer is listed in the certificate as

Edit

And directly fetching the certificate

$ openssl s_client -showcerts -servername www.upfront-rentals.com -connect www.upfront-rentals.com:443 < /dev/null
CONNECTED(00000003)
depth=0 CN = upfront-rentals.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = upfront-rentals.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = upfront-rentals.com
verify return:1
40072B3A45780000:error:0A00018A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2086:
---
Certificate chain
 0 s:CN = upfront-rentals.com
   i:C = US, O = Let's Encrypt, CN = R10
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov  6 05:21:13 2024 GMT; NotAfter: Feb  4 05:21:12 2025 GMT
-----BEGIN CERTIFICATE-----
MIIFETCCA/mgAwIBAgISA38qGQZ+3KBJHvFMSNdwPe5bMA0GCSqGSIb3DQEBCwUA
MDMxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQwwCgYDVQQD
EwNSMTAwHhcNMjQxMTA2MDUyMTEzWhcNMjUwMjA0MDUyMTEyWjAeMRwwGgYDVQQD
ExN1cGZyb250LXJlbnRhbHMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAwjDI36SPtV2El2630dwspwyuuxbTIFDE8AceeLuFE/c5dM4lG7SLcKHx
O8POrBy/RZPzjdPUo5NceexC5z5DxzYvpYEcGX/d0xjZgHWVPv7CJBkOEKOLYKfF
PU2X0UbNAG0U36xa8wJoufYTQRzwQySnUFhAXHw1346vJjN+VzFX/YHMkZLDAvN9
u/GDAm23oPipiY0tV4KwJiR2RgRe0YQg8UZau8iq6i6ja7BNkQRHJA0ePSchHLIl
JiR3A35n6BXNjg+7SXXxL9Hdc68cawIqD7rS6fbELDsF3J4SZBwMJUrBOYEGWcBw
c/peNM/Om0DdgDNVOpTDsO4PPEwAOQIDAQABo4ICMjCCAi4wDgYDVR0PAQH/BAQD
AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAA
MB0GA1UdDgQWBBRnHNJw8LQB4lpG1w1UxUM5agWh4DAfBgNVHSMEGDAWgBS7vMNH
peS8qcbDpHIMEI2iNeHI6DBXBggrBgEFBQcBAQRLMEkwIgYIKwYBBQUHMAGGFmh0
dHA6Ly9yMTAuby5sZW5jci5vcmcwIwYIKwYBBQUHMAKGF2h0dHA6Ly9yMTAuaS5s
ZW5jci5vcmcvMDcGA1UdEQQwMC6CE3VwZnJvbnQtcmVudGFscy5jb22CF3d3dy51
cGZyb250LXJlbnRhbHMuY29tMBMGA1UdIAQMMAowCAYGZ4EMAQIBMIIBBgYKKwYB
BAHWeQIEAgSB9wSB9ADyAHcAouMK5EXvva2bfjjtR2d3U9eCW4SU1yteGyzEuVCk
R+cAAAGTACEC/gAABAMASDBGAiEAoHl9FPmvXDBVSIqlT0Bralv/UfQlHIvRAlPZ
B20hvqMCIQDIfzQc4he9USYcVUUu8yt4ix5dD1PWSVN6eWi5UFmxfwB3AM8RVu7V
Lnyv84db2Wkum+kacWdKsBfsrAHSW3fOzDsIAAABkwAhAy8AAAQDAEgwRgIhAK2N
SMYM18EPxigUpWGgigkaAiQYopmkcW0chj4J6HFdAiEA/Bp7trn5/BLXp+rspQgV
j3gj94wyai/85XGu2eKRZQIwDQYJKoZIhvcNAQELBQADggEBAAoYII8yDM4ITTyI
PxEFrwnDx+zOfJUKhGQ9Ii8XkmlW+rc61bw1ZY32Q67jAjtaXmpGAg93+olhbcQw
NiRkYc3wB3jUlb/BH/eji/83WQLqvc+ofdkFc4khwnL6NsH8Dj3b9k7uU30DubDL
R5r6Vnq/KlGvppixHatltrZw5e1LL+F4tpCZHIetYYX8hfdsEGIL1cunKLD7KP9O
n2CE4Uexu1WeE07LIRpyBa+8Qtwu6JZbQdQbC5ZwJafpj8ZemBqKZaVC0LVE426A
BZI/FNMYfYlW38rNukei2MnNu8IoaWaTDc3HYkID6GNqTTvTD6gXK2VIh+CX81lW
Gx9hIHY=
-----END CERTIFICATE-----
---
Server certificate
subject=CN = upfront-rentals.com
issuer=C = US, O = Let's Encrypt, CN = R10
---
No client certificate CA names sent
---
SSL handshake has read 2033 bytes and written 332 bytes
Verification error: unable to verify the first certificate
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1734913290
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
---

You can see:
Certificate chain
0 s:CN = upfront-rentals.com
i:C = US, O = Let's Encrypt, CN = R10

2 Likes

dear osiris,

regarding the 1024 key size

is a "Server Temp Key: ECDH, P-256, 256 bits"

an improvement ?

thank you webprofusion,

the server was indeed configured to request client certificates and changing it solved the problem in question. :slight_smile:

2 Likes

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.)

2 Likes

thank you very much Osiris,
happy new year to you and yours
:slight_smile:

1 Like

Thanks, you too.

However, looking at SSL Server Test: www.upfront-rentals.com (Powered by Qualys SSL Labs) (the tool is online again), I do not see any elliptic curve DH in the key exchanges. Just cipher suits marked as "WEAK" or even "INSECURE".

1 Like

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