My SSL certificate appears to be self signed


When I tested my site with whynopadlock it shows the message bellow:
Your SSL certificate appears to be self signed.
I don't know why I didn't do anything, my domain is:

Can you please help me.

Hi @pipa_85,

It appears that you're serving your Fortigate firewall's TLS certificate, rather than some other certificate. Here's some openssl output.

$ echo | openssl s_client -connect -servername
depth=1 C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG3H1ETB19904366, emailAddress =
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG3H1ETB19904366, emailAddress =
verify return:1
depth=0 CN =
verify return:1
Certificate chain
 0 s:CN =
   i:C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG3H1ETB19904366, emailAddress =
 1 s:C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG3H1ETB19904366, emailAddress =
   i:C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG3H1ETB19904366, emailAddress =
Server certificate
subject=CN =

issuer=C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = FG3H1ETB19904366, emailAddress =

No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
SSL handshake has read 2833 bytes and written 452 bytes
Verification error: self signed certificate in certificate chain
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 22231BBE2B52C30F1E854B44A18A2371B547B64FD1C1F833EC95CAE2023B36F0
    Master-Key: A7DD08FB37AD6AA41EFD0861AAB9FC3051A92E80EE606D16D022FBCEAD9F6D116EB4C086487795E1312147E37E555CD0
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1633017598
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
    Extended master secret: yes
1 Like

Looks like the FG may be doing SSL inspection (in both directions).
Which, in and of itself, it not the problem.
The problem occurs when the FG isn't using a trusted cert (with the requested name on it).

You could try disabling inbound SSL inspection to that system - until the cert can be found/created/used.


I don't know how to do that I am totaly lost
Our Fortiweb is configured in reverse proxy mode
I would like to understand why it says that the certificate is issued by Fortinet, not by Let's encrypt

Do you have support from Fortinet?

1 Like

No, I don't.
I don't know what happened, I didn't touch the configuration, suddenly I had this problem

AND it is now also doing HTTPS inspection?

1 Like

I don't know, How to know that please ?

Sorry, I'm not Fortinet support.

1 Like

It appears to be a Fortigate (and Palo Alto) related issue with not updating the certificate store. If you hadn't found it already, lots of users discussing today's cert expiration over on Reddit Fortigate forum. All of a sudden we are getting SSL Certificate expired while using deep packet inspection today : fortinet


Thank you for your message which led me to this page:

In this page they explain that the DST Root CA X3 will expire on September 30, 2021 which may explain the problem I am having, because we imported the following intermediate certificates into forti web:

What should I do ?
Acoording to Nummer378 in this post my site should be serving two intermediates (R3 signed by ISRG Root X1 and ISRG Root X1 signed by DST Root CA X3)
With what should I replace DST Root CA X3 ?

You may not need to do anything with it - for sites/certs that you serve.
Just remove it from their chain.
[I can't really even say how that is done within FortiWeb]

For remote sites (access via proxy or HTTPS inspection) there is nothing you can do to change the servers on the Internet.
You could speak with FortiNET about what they recommend.
[I'm pretty sure they must have published some official statement on this today]
[I'll try to hunt that down now...]

1 Like

In fortiweb I have configured the server policy as follows:

maybe CA X3 Root DST is included in the full chain, that's why I still have the problem right ?.
If I generate a new certificate for my website, will the problem go away?

Maybe the issue is similar to what is described here what do you think?

This is what I've been able to gather:

1 Like

That's what I was reading, the workarounds must be performed on the fortigate firewall but I do not have access to it, I must contact the firewall manager. Thank you very much for your help.

the problem occured because the root certificate that is used by LetsEncrypt has expired DST Root CA X3 Expiration (September 2021) - Let's Encrypt

I am wondring if I generate a new certificate, will let's encrypt remove the expired root CA from the full chain?

1 Like

It is worth the effort.
[and it can't possibly make things any worse - famous last words]


So from what I understand, I no longer need the intermediate certificate ISRG Root X1 signed by DST Root CA X3 so I deleted it from fortiweb, I kept only the intermediate certificate R3 signed by ISRG Root X1:

Tomorrow I will generate another certificate and I will upload (fullchain) it into fortiweb.

1 Like

I applied the first workaround from this link and it worked.
But there is another problem, on some devices the problem of the certificate which is not current is still displayed and even for the let's encrypt and whynopadlock sites as you can see in the screenshots below:

So it's not a problem at my level
What should be done to get around this problem

You may need to install the "ISRG Root X1 (self-signed)" into your certificate trust store.

[and maybe reboot]

1 Like

@pipa_85 check out Fortinet and Expiring Let’s Encrypt Certificates