ssl-vpn certificate error - chain not returned

[#1]

Hi, Quick Summary: MR5 returns complete certifcate chain when HTTPS to ADMIN Port MR5 only returns the primary certifcate when HTTPS to SSL-VPN Port Bug / Issue with code, not certifcate, or certifcate chain, same cert is used for both ADMIN-Cert and SSL-VPN Cert, so should work for both! I am using a FG500A with MR5 (0559) I have installed a wildcard public (digicert) certificate under VPN->Certificates->Local Certificates using Import Certifcate with required Certificate File and Key File. Installed successfully. I have installed the intermeditary DigitCert Global CA certifcate under CA Certificates I have installed the Entrust.net Secure Server Certification Authority under CA Certificates Now after PUTTY onto Firewall and configured the admin server certificate to use the public cert as a test config global config system global set admin-server-cert starcert end Now when I https://<FQDN of Firewall> I get the firewall Login Page without any certifcate error Looking at the Certifcate returned in IE I see the correct public cert, and when I click on certifcation chain I see ALL the certs in the chain - no issues!! Now I configure SSL-VPN to use the starcert Then I https://<FQDN of Firewall:10443/remote> I get a certifcate error!! When I check the returned certificate the CORRECT public cert has been returned!! The failure indicates I have a valid name, and the name matches the web site I am browsing but that the certificate cannot be verified! The issue is that the CERTIFCATE CHAIN has NOT been returned, most notably the intermediate certifcate has not been returned. Hence IE cannot verify the complete chain and it complains! The SSL specificate allows for the server to return not only the SSL certifcate but all certificates in the chain. The FortiGate correctly returns all certifcates in the chain when browsing to the admin port, but only returns the SSL certificate when browsing to the SSL-VPN port. Of course I could just go ahead and install the DigiCert intermediate authority on my PC and the error will go away. But that defeats the purpose of the public certificate, and creating the seamless experience that I was after. Has anyone: (a) Come across this before (b) Know of a way to correct it (!) (c) Point out what I am doing wrong (?!!?) Thanks in advance, VirtualG

[#2]

Hi, this was quite some time ago, did you manage to find an answer to this? Because I' m having the exact same problem. I' m not using the latest release of FortiOS, but before upgrading it would be nice to know if it actually fixes the problem. I' ve searched through all the documentation I could find and I can' t find anything about intermediate certificates at all. Anyone else managed to install a Verisign certificate for VPN-SSL? And in that case how did you get the certificate chain to work?

[#3]

Hi Jonas, Unfortunately I do not have a solution to this problem. Current OS still exhibits this behaviour. Makes a public certificate virtually worthless for SSL-VPN connectivity because you must install the ' chain' on each machine that is going to use the SSL-VPN first. You would think that Fortinet QA would have picked this one up?! Cheers, Graham.

[#4]

oddly enough.. it works for me now.. and I don' t think I did anything besides wait a few hours. I' m running build0483 on a 300A. The last change I did was to extract Verisigns root certificate from IE and upload that to the Fortigate, then I also changed from the real certificate to the built-in on the vpn-ssl configuration page, applied, and changed back. After this I tried again without success. Either I had to wait, for some unknown reason. Or i forgot to close down the browsers before i tried again.

[#5]

It seems to fail only if there is an INTERMEDIATE certificate required, and that INTERMEDIATE certificate is not trusted by your client by default. Meaning you have: Root CA -> Intermediate CA -> Your Certificate Even if you upload Your Certificate (Private Key), the Intermediate CA (Public Key), and the Root CA (Public Key) to the Fortinet, the fortinet will not return Your Certificate (Public Key) - Intermediate CA (Public Key) - Root CA (Public Key) when you browse to it using the REMOTE (SSL VPN) web page. It will return the entire chain when you browse to say the administration web page on the fortinet. The issue will be visible to the client if: The certificate you use has an intermediate CA, and that intermediate CA is unknown to the client. In this situation the client will be unable to confirm the authenticity of your certificate because it will only know the Root CA, and your Certificate and cannot verify the complete chain. It sounds like your certificate does not have an intermediate CA, hence the bug I have described does not apply to you. e.g. Root CA -> Your Certificate = OK or Root CA (Trusted on client) -> Intermediate CA (Trusted on client by default) -> Your Certificate = OK but Root CA (Trusted on client) -> Intermediate CA (NOT trusted on client) -> Your Certificate (Not trusted on client) = Failure when using SSL-VPN web site. Cheers.

[#6]

I do have an intermediate CA.. Verisign started using them last year or so.. the new certificates I' ve gotten from them has been with an intermediate. I uploaded the Certificate to " Local certificates" and the intermediate and verisigns root cert to " CA Certificates" ..

[FortiRack_Eric]

This may not work, as the FG box doesn' t support intermediate root CA' s. You have to acquire a SSL cert that doesn' t use an intermediate. Regards, Eric.

[#8]

Hi Eric, Well the FG sort of supports intermediate certs. It does for the administration certificate (there it will correctly return all certificates in the chain to the browser), but not for the SSL-VPN web site - It will not return the intermediate certificates even though they have been uploaded to the FG :-( So, I guess, " It doesn' t support" is sort of right - but it is still a bug! I am confused that Jonas seems to imply he has this working. I would suspect that his browser already has the intermediate certificate in its trusted CA or trusted intermediate certificates store on his client, hence even though the FG SSL-VPN web site does not return the intermediate certificates his computer already knows about them, hence it works - just a guess. It is interesting that many SSL certificate vendors are releasing certificates that have intermediatories now. About time FG started following the SSL standard? ;-) (I would be more than happy to be wrong about this, if someone could point out what I am doing wrong that would be great!). Cheers!

[FortiRack_Eric]

It depends on what you call working and supporting. It all has to do with the way PKI - certs work. As there is no seperate tab for intermediate root certs, it is not supported. If you load the intermediate cert in your browser from which you are connecting then you may have no issue. Furthermore more and more SSL vendors are moving away from intermediate certs. You can buy a basic ssl cert from Equifax for as little as 30-40$ per year. (No intermediate). Cheers, Eric

[#10]

seems i spoke too soon.. i dont have any complains from the browser about the certificate as i said earlier.. but i can' t get the tunnel to connect after i changed the url to the certificate url, instead of going to the ip-address. i can make it all work if i connect to the ip-address, connects fine etc, but ofcourse it complains about the certificate not being for that url. if i connect to the certificate url in firefox it will show the activex plugin, but refuse to connect the tunnel. in IE it just wont load the page, keeps loading forever. only thing i figured was that it might have to do with me installing the plugin from the IP-address and not the url, so i' ve tried uninstalling it. since the " uninstall" button doesn' t do much, i managed to find the files that got installed to firefox and deleted them by hand. still no go, even though i get to install the plugin anew, it still behaves the same way. changing back and connecting to the IP, and it works. Eric, as for FG not supporting intermediate certificates, is this something you know or just assume by the lack of a tab? i' ve seen quite a few firewalls/routers etc that doesn' t have a specific tab to load an intermediate, you go around it by joining the site-certificate and intermediate into one file, or similar.