- weak or small keysize
- compromised cert/key or CAtrust broken
- server-certificate has been revoked
- certificate expiration issues
- upwind SSL inspection devices ( IPS )
- other security related issues etc.....
1st let's look at the openssl process for crafting my selfsign-certificate & key combo.
In a true organization, you would generate a CertificateSigningRequest and have a valid CA sign the CSR using a validate signing certificate. This could be a public CA or a organization internal CA.
Here's my openssl usage;
note: for demo, I crafted this certificate for 1 day. In reality you will determine the lifetime for the certificate ( e.g 1 2 5 10 years , or whatever your needs are ).
Next, you will login into the fortigate via the cli and copy the key.pem and cert.pem contents.
note: I find it easier to copy the text output. Fortigate WebGUI has had issues with the certification importation in the past YMMV. Alot of earlier 5.2.2 users complain of certificate uploads via the WebGUI failing.
For the key.pem extract the lines including and between the following;
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
edit < new name>
set password < passphrase for the key>
set private-key < insert the fill private-key with the above lines enclosed between "" >
set certificate < insert the certificate with the lines listed below enclosed between "" >
Here's an abbr sample for demo purpose.
set password mysuperduperpassphrase
set private-key "-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----"
set certificate "-----BEGIN CERTIFICATE-----
Now you can validate the certificate within the WebGUI .
note: You will need to have the WEBgui enabled for showing the certificates.
Okay, now we have to tell our fortigate ssl-vpn-settings configuration to use the certificate.
That's how simple and quick it takes for installing a new certificate/key within a Fortigate Appliance.
- keep the cert and private-key secured
- optional you can extract the private-key passphrase via openssl, if you do this step you don't need to set the set password command
- always validate the key details ( DATEs,SERIAL#, keysize, FINGERPRINT etc...)
- You can delete the certificates via the CLI or WEBgui
- If you fear the NSA or your Gov, craft a csr with a 2k bit or 4k bit keysize
- search for my other cool openssl tricks/tips
Observations from the cockpit;
- The MACOSX Forticlient 5.2.4 hates certificates with a 8K or greater private-keysize for tunnel-mode but the webportal will work with your webbrowser. The Tunnel mode does not complete the ssl-handshake. This could be a flaw in the actual forticlient ( I've tested this on both Window, Android & MACOSX with various results )
- Android will not work with a 16k bit keysize. I believe the cpu size is the reason behind it. Using diag debug app sslvpn -1 show the android client never read the certificate and stalls. So the SSL-handshake halts when using tunnel-mode.
- Windows hangs up more than 80% of the the time with a keysize of 16384bits when operating in tunnel-mode. Could be a issue with the forticlient. The web-portal works fine with all browser that I tested including IE.
- If you copy the private-key/certificate via the cli, be aware of any input buffer with the copy/pastes process.
- keysize larger than 4k bit are slower for the initial forticlient Session establishment.
- The fortclient continue it's ssl establishment with a certificate that was obviously expired or if the clock where push pass the certificate dates. I thought this was very poor security-practice on FTNT behalf and the forticlient show have acted like chrome/opera/safari browser and warn you or stop the connection .
NSE ( network security expert) and Route/Switching Engineer
kfelix -----a----t---- socpuppets ---dot---com
=( @ @ )=