Skip to main content
alin_stan
alin_stan
New Member
June 27, 2015
Solved

SSL VPN Certificat authentication

  • June 27, 2015
  • 2 replies
  • 10156 views

Hi,

 

I want to implement SSL VPN client to site certificate authentication.

The things I tried till now :

1. Set the Fortinet_CA_SSL Proxy certificate in the ssl vpn settings as required for clients, downloaded the fortinet ca ssl proxy certificate on a client computer, installed it and tried to connect - didn't work.

2. Generate a certificate request, signed it on a windows server certificate authority and then import it on fortigate. I installed the same certificate I imported on fortigate on a client computer and tried to connect - didn't work.

 

I don't think I understanded well the concepts of certificates and what certificate should I use on the fortigate unite and what certificates I should use on client computers.

 

Another thing I tried to experiment related to certificates is setting the certificate for GUI administration of the fortigate and then importing it to a computer. I still get the warning when I connect with a browser on the fortigate. This is not very important but I thought it would be for my understanding about certificates.

 

The only thing that worked well for me was ssl deep inspection. I set the certificate to use for deep inspection (fortinet ca ssl proxy) and then I installed it on a computer. After that I didn't receive warnings when I open https websites, so it worked.

 

Can anyone give me a step by step guidance ?

Thank you very much!

 

    Best answer by Christopher_McMullan

    It all comes down to what the purpose of each certificate is, either the built-in defaults or ones you generate and import. The CA SSL proxy certificate is specifically meant for the FortiGate to act as a "CA on-the-fly", and re-write the certificates of sites that clients try to visit that you want to place under deep inspection. The FortiGate intercepts their session from the start, and replies as an impersonation of the real destination server. It takes the real server's certificate as a template, and re-writes the issuer portion so that, instead of the site's authority being guaranteed by Entrust, it's now guaranteed by something like "FGT80C3911605328". Obviously, this makes browsers scream unless the CA certificate is imported ahead of time.

     

    For GUI identification, if you generate a CSR on the FortiGate and have it signed by a third-party CA (like Entrust), then select it for SSLVPN access or GUI management, you should have no warnings even without having to import the certificate. The FortiGate is now recognized as a web server by a third-party CA.

     

    For SSLVPN certificate authentication, you're branching out into a third scenario: client identification. The GUI or tunnel is still authenticated to the client based on the certificate in the last paragraph above, but now clients have to prove who they are to the FortiGate as well using a certificate, instead of a username/password combination. In this case, the FortiGate needs to know who issued a certificate to the client. Most often, it's an enterprise CA. You need to do two things beforehand:

    (i) generate a client cert;

    and (ii) import the CA cert to the FortiGate under the CA section.

     

    The GUI sections can be confusing unless you've already become an old hand at deploying this kind of infrastructure. There are Local, CA, and Remote sections. In the case of scenario #3, the CA store is for the FortiGate: hey, client, that's great that you have a cert. Who had the authority to vouch for your identity? If the CA cert has been imported, then you have a green light to bring up a tunnel. All other certificates for web elements (the FGT has an Apache server for GUI access, captive portals, SSLVPN web portals, etc.) or deep inspection are stored under Local, since they either identify the (local) FortiGate, or allow it to act as a CA in its own right.

     

    Does that help at all?

    2 replies

    Christopher_McMullan
    Staff
    Christopher_McMullanAnswer
    Staff
    June 29, 2015

    It all comes down to what the purpose of each certificate is, either the built-in defaults or ones you generate and import. The CA SSL proxy certificate is specifically meant for the FortiGate to act as a "CA on-the-fly", and re-write the certificates of sites that clients try to visit that you want to place under deep inspection. The FortiGate intercepts their session from the start, and replies as an impersonation of the real destination server. It takes the real server's certificate as a template, and re-writes the issuer portion so that, instead of the site's authority being guaranteed by Entrust, it's now guaranteed by something like "FGT80C3911605328". Obviously, this makes browsers scream unless the CA certificate is imported ahead of time.

     

    For GUI identification, if you generate a CSR on the FortiGate and have it signed by a third-party CA (like Entrust), then select it for SSLVPN access or GUI management, you should have no warnings even without having to import the certificate. The FortiGate is now recognized as a web server by a third-party CA.

     

    For SSLVPN certificate authentication, you're branching out into a third scenario: client identification. The GUI or tunnel is still authenticated to the client based on the certificate in the last paragraph above, but now clients have to prove who they are to the FortiGate as well using a certificate, instead of a username/password combination. In this case, the FortiGate needs to know who issued a certificate to the client. Most often, it's an enterprise CA. You need to do two things beforehand:

    (i) generate a client cert;

    and (ii) import the CA cert to the FortiGate under the CA section.

     

    The GUI sections can be confusing unless you've already become an old hand at deploying this kind of infrastructure. There are Local, CA, and Remote sections. In the case of scenario #3, the CA store is for the FortiGate: hey, client, that's great that you have a cert. Who had the authority to vouch for your identity? If the CA cert has been imported, then you have a green light to bring up a tunnel. All other certificates for web elements (the FGT has an Apache server for GUI access, captive portals, SSLVPN web portals, etc.) or deep inspection are stored under Local, since they either identify the (local) FortiGate, or allow it to act as a CA in its own right.

     

    Does that help at all?

    alin_stan
    alin_stanAuthor
    New Member
    August 5, 2015

    Thank you for your answer and sorry i am so late :).

    I was doing the configuration correctly but my certificates weren't ok. I understanded how to use them and I succeeded with the config.

    Terms & ConditionsAccessibility statement