Technical Tip: How to avoid certificate error message by chaining Root CA and Intermediate CA certificates on FortiGate
Description
This article describes that while using third-party certificates signed by intermediate CA/root CA, sometimes FortiOS will not send the complete certificate chain to the client. This occurs due to an incorrect configuration and gives a certificate error message on the client browser.
This article helps to avoid such error messages.
Scope
This article applies to the following authentication types:
- Admin WebUI login to FortiGate.
- SSL VPN authentication to FortiGate.
- Captive Portal authentication over HTTPS to FortiGate.
This article applies to the following certificate types:
- Locally signed certificates.
- Certificates signed by well-known CAs.
Solution
While authenticating against the captive portal of a FortiGate, a certificate error message is sometimes displayed. The certificate error can be caused by several Alert messages as described in the TLS/SSL RFCs. Viewing the developer tools available in the web browser helps narrow down the exact root cause of the certificate error message.
In this case, the certificate error message was caused by an invalid/no chain of certificates verifying the authenticity of the server certificate provided in the SSL/TLS handshake.
The certificate chain is missing, as shown in the certification path tab:
Select Export Packet Bytes and save the file as certificate.cer, and open the certificate.cer, which looks like below.
Go to the FortiGate GUI and upload the public key/certificate of Root CA and Intermediate CA in the CA Certificate section in PEM/cer format.
Make sure that you have the Root CA and Intermediate CA under the External CA certificates.
In new versions, the location is under 'Remote CA Certificate':
Restart the authd process:
For SSL VPN web services to take effect, either restart the SSLVPND daemon or reconfigure the server certificate in the SSL VPN settings by switching to another certificate and reverting back to the original certificate.
Take note that restarting the SSLVPND daemon or reconfiguring the SSL VPN server certificate will interrupt active SSL VPN connections.
On the browser, ensure that the Root CA is present/installed/trusted. Intermediate CA doesn't need to be installed on the browser because the intermediate CA will be sent in the SSL/TLS handshake by the FortiGate.
Re-open the browser and access any web page. This redirects to the captive portal login page on the FortiGate.
The certificate chain is present this time, and no error is seen on the browser.
Verify using Wireshark to capture the SSL/TLS Handshake.
Another option is to use OpenSSL to validate the certificate chain:
# openssl s_client -verify 5 -connect 192.168.170.33:10443 </dev/null
verify depth is 5
CONNECTED(00000003)
depth=2 C = MX, ST = CDMX, L = Mexico, O = Fortinet, OU = TAC, CN = CA_XCA-root, emailAddress = oxxx@fortinet.com
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=2 C = MX, ST = CDMX, L = Mexico, O = Fortinet, OU = TAC, CN = CA_XCA-root, emailAddress = oxxx@fortinet.com
verify return:1
depth=1 C = MX, ST = CDMX, L = MEXICO, O = TAC XCA, OU = SOPORTE, CN = CA_XCA_2025, emailAddress = oxxx@fortinet.com
verify return:1
depth=0 C = MX, ST = MEXICO, L = DCMX, O = MEXICOTAC, OU = TACMEX, CN = *vpn2.tacmexico.mx, emailAddress = oxxx@fortinet.com
verify return:1
---
Certificate chain
0 s:/C=MX/ST=MEXICO/L=DCMX/O=MEXICOTAC/OU=TACMEX/CN=*vpn2.tacmexico.mx/emailAddress=oxxx@fortinet.com
i:/C=MX/ST=CDMX/L=MEXICO/O=TAC XCA/OU=SOPORTE/CN=CA_XCA_2025/emailAddress=oxxx@fortinet.com
1 s:/C=MX/ST=CDMX/L=MEXICO/O=TAC XCA/OU=SOPORTE/CN=CA_XCA_2025/emailAddress=oxxx@fortinet.com
i:/C=MX/ST=CDMX/L=Mexico/O=Fortinet/OU=TAC/CN=CA_XCA-root/emailAddress=oxxx@fortinet.com
2 s:/C=MX/ST=CDMX/L=Mexico/O=Fortinet/OU=TAC/CN=CA_XCA-root/emailAddress=oxxx@fortinet.com
i:/C=MX/ST=CDMX/L=Mexico/O=Fortinet/OU=TAC/CN=CA_XCA-root/emailAddress=oxxx@fortinet.com
Points to note:
- Public key of the Root and Intermediate CA needs to be uploaded to FortiGate, as Remote CA certs.
- The following two CLI commands are in place.
- Instead of IP, FQDN should be used, and the FQDN should exist on CN or SAN.
Related documents: