Hello,
Thank you very much for your help, indeed, I only imported the R3 signed by ISRG Root X1. Now, I imported also the ISRG Root X1 signed by DST Root CA X3 so, the problem is solved, I mean it works with google chrome and the whynopadlock and ssl Labs sites dont show any errors.
But I will see if the users don't complain.
The links you provided me are very interesting but they concern the version 6.4 of fortiweb and above, unfortunately, the version that we have is much lower, it doesn't support the integration with Let’s Encrypt yet to automatiquely generate server's certificate. So, I am obliged to do it manualy.
Now I will answer your question, why do I have to manually manipulate intermediate certificates.
In 2017, I wanted to set up https for our site, so, I generated the certificate and I configured the apache virtual host to serve it but It deosn't work, when I test my site with whynopadlock site, it always detects the Fortiweb certificate rather than the let's encryp certificate (as you can see it here). By doing some research, I found in the Fortiweb documentation that it is necessary to import the CA's certificate and the server's certificate into fortiweb (you can doawload the fortiweb's administration guide here on page 295, 298 and 308), At that time, we had the version 5.3 of fortiweb, so, I imported into fortiweb cert.pem as well as privkey.pem. It is also written in the documentation that if the certificate is not signed by a root CA then, I must also import the intermediate certificate (ie: the certificate of let's encryp which is an intermediate certificate, page 310) finally. in the server policy I had to select the certificate of my server (cert.pem) and the intermediaries. Doing that, the https worked very wel. Below, the configuration of the server policy:
Currently, I import fullchain.pem and privkey.pem (I no longer use cert.pem). I said to myself the last thirsdays I should not import the intermediate certificates manualy since the fullchain.pem contains the server's certificate as wel as the intermediate certificates, so, I tryed to not use (not select) the Inter_group1 (wich contains the intermediaries) in the server policy but when I did that, the whynopadlock indicates that I have an invalid or missing intermediate certificate.
So,I had to select that group again in the server policy, knowing that the Inter_group1 group contains the R3 signed by ISRG Root X1 and the ISRG Root X1 signed by DST Root CA X3
I will continue my research to find a solution not to manually import intermediate certificates with our current version of forti web, while waiting to update fortiweb to the version 6.4.0 that supports the integration with let's encrypt to automatiquely generate server's certificate.