Tag Archives: fortinet product matrix

IPsec VPNs and certificates

IPsec VPNs and certificates

Certificate authentication is a more secure alternative to preshared key (shared secret) authentication for IPsec VPN peers. Unlike administrators or SSL VPN users, IPsec peers use HTTP to connect to the VPN gateway configured on the FortiGate unit. The VPN gateway configuration can require certificate authentication before it permits an IPsec tunnel to be established. See Authenticating IPsec VPN users with security certificates on page 535 .

 

Certificate types on the FortiGate unit

There are different types of certificates available that vary depending on their intended use. FortiOS supports local, remote, CA, and CRL certificates.

 

Local certificates

Local certificates are issued for a specific server, or web site. Generally they are very specific, and often for an internal enterprise network. For example a personal web site for John Smith at www.example.com (such as http://www.example.com/home/jsmith) would have its own local certificate.

These can optionally be just the certificate file, or also include a private key file and PEM passphrase for added security.

For information about generating a certificate request, see Generating a certificate signing request on page 526. For information about installing a local certificate, see Obtaining and installing a signed server certificate from an external CA on page 529

 

Remote certificates

Remote certificates are public certificates without a private key. For dynamic certificate revocation, you need to use an Online Certificate Status Protocol (OCSP) server. The OCSP is configured in the CLI only. Installed Remote (OCSP) certificates are displayed in the Remote Certificates list. You can select Import to install a certificate from the management PC.

 

CA root certificates

CA root certificates are similar to local certificates, however they apply to a broader range of addresses or to whole company; they are one step higher up in the organizational chain. Using the local certificate example, a CA root certificate would be issued for all of www.example.com instead of just the smaller single web page.

 

Certificate revocation list

Certificate revocation list (CRL) is a list of certificates that have been revoked and are no longer usable. This list includes certificates that have expired, been stolen, or otherwise compromised. If your certificate is on this list, it will not be accepted. CRLs are maintained by the CA that issues the certificates and includes the date and time when the next CRL will be issued as well as a sequence number to help ensure you have the most current version of the CRL.

 

Certificate signing

The trust in a certificate comes from the authority that signs it. For example if VeriSign signs your CA root certificate, it is trusted by everyone. While these certificates are universally accepted, it is cumbersome and expensive to have all certificates on a corporate network signed with this level of trust.

With self-signed certificates nobody, except the other end of your communication, knows who you are and therefore they do not trust you as an authority. However this level is useful for encryption between two points — neither point may care about who signed the certificate, just that it allows both points to communicate. This is very useful for internal networks and communications.

A general rule is that CA signed certificates are accepted and sometimes required, but it is easier to self-sign certificates when you are able.

For more on the methods of certificate signing see Generating a certificate signing request on page 526.

 

Certificate-based authentication

Certificatebased authentication

This section provides an overview of how the FortiGate unit verifies the identities of administrators, SSL VPN

users, or IPsec VPN peers using X.509 security certificates. The following topics are included in this section:

  • What is a security certificate?
  • Certificates overview
  • Managing X.509 certificates
  • Configuring certificate-based authentication
  • Example — Generate a CSR on the FortiGate unit
  • Example — Generate and Import CA certificate with private key pair on OpenSSL
  • Example — Generate an SSL certificate in OpenSSL

 

What is a security certificate?

A security certificate is a small text file that is part of a third-party generated public key infrastructure (PKI) to help guarantee the identity of both the user logging on and the web site they where they are logging in.

A certificate includes identifying information such as the company and location information for the web site, as well as the third-party company name, the expiry date of the certificate, and the public key.

FortiGate units use X.509 certificates to authenticate single sign-on (SSO) for users. The X.509 standard has been in use since before 2000, but has gained popularity with the Internet’s increased popularity. X.509 v3 is defined in RFC 5280 and specifies standard formats for public key certificates, certificate revocation lists, and a certification path validation algorithm. The unused earlier X.509 version 1 was defined in RFC 1422.

The main difference between X.509 and PGP certificates is that where in PGP anyone can sign a certificate, for X.509 only a trusted authority can sign certificates. This limits the source of certificates to well known and trustworthy sources. Where PGP is well suited for one-to-one communications, the X.509 infrastructure is intended to be used in many different situations including one-to-many communications. Some common filename extensions for X.509 certificates are listed below.

 

Common certificate filename extensions

 

Filetype Format name Description
 

.pem

 

Privacy Enhanced Mail (PEM)

 

Base64 encoded DER certificate, that uses: “—–BEGIN CERTIFICATE—–” and

“—–END CERTIFICATE—–”

 

.cer

.crt

.der

Security CERtificate

Usually binary DER form, but Base64-encoded cer- tificates are common too.

.p7b

.p7c

Structure without data, just certificates or CRLs.

PKCS#7 is a standard for signing or encrypting (offi- cially called “enveloping”) data.

.p12          PKCS#12                                                      May contain certificate(s) (public) and private keys

(password protected).

.pfx           personal information exchange (PFX)          Older format. Came before PKCS#12. Usually today data is in PKCS#12 format.

 

 

Certificates overview

Certificates play a major role in authentication of clients connecting to network services via HTTPS, both for administrators and SSL VPN users. Certificate authentication is optional for IPsec VPN peers.

  • Certificates and protocols
  • IPsec VPNs and certificates
  • Certificate types on the FortiGate unit

 

Certificates and protocols

There are a number of protocols that are commonly used with certificates including SSL and HTTPS, and other certificate-related protocols.

 

SSL and HTTPS

The secure HTTP (HTTPS) protocol uses SSL. Certificates are an integral part of SSL. When a web browser connects to the FortiGate unit via HTTPS, a certificate is used to verify the FortiGate unit’s identity to the client. Optionally, the FortiGate unit can require the client to authenticate itself in return.

By default, the FortiGate unit uses a self-signed security certificate to authenticate itself to HTTPS clients. When the certificate is offered, the client browser displays two security messages.

  • The first message prompts users to accept and optionally install the FortiGate unit’s self-signed security certificate.

If the user does not accept the certificate, the FortiGate unit refuses the connection. When the user accepts the certificate, the FortiGate login page is displayed, and the credentials entered by the user are encrypted before they are sent to the FortiGate unit. If the user chooses to install the certificate, the prompt is not displayed again.

  • Just before the FortiGate login page is displayed, a second message informs users that the FortiGate certificate distinguished name differs from the original request. This message is displayed because the FortiGate unit redirects the connection (away from the distinguished name recorded in the self-signed certificate) and can be ignored.

Optionally, you can install an X.509 server certificate issued by a certificate authority (CA) on the FortiGate unit. You can then configure the FortiGate unit to identify itself using the server certificate instead of the self-signed certificate.

For more information, see the FortiOS Handbook SSL VPN guide.

After successful certificate authentication, communication between the client browser and the FortiGate unit is encrypted using SSL over the HTTPS link.

 

Certificaterelated protocols

There are multiple protocols that are required for handling certificates. These include the Online Certificate Status Protocol (OCSP), Secure Certificate Enrollment Protocol (SCEP), and Server-based Certificate Validation Protocol (SCVP).

 

Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) allows the verification of X.509 certificate expiration dates. This is important to prevent hackers from changing the expiry date on an old certificate to a future date.

Normally certificate revocation lists (CRLs) are used, but OCSP is an alternate method available. However a CRL is a public list, and some companies may want to avoid the public exposure of their certificate structure even if it is only invalid certificates.

The OSCP check on the certificate’s revocation status is typically carried out over HTTP with a request-response format. The authority responding can reply with a status of good, revoked, or unknown for the certificate in question.

 

Secure Certificate Enrollment Protocol

Secure Certificate Enrollment Protocol (SCEP) is an automated method of signing up for certificates. Typically this involves generating a request you send directly to the SCEP service, instead of generating a file request that may or may not be signed locally.

 

Serverbased Certificate Validation Protocol

Server-based Certificate Validation Protocol (SCVP) is used to trace a certificate back to a valid root level certificate. This ensures that each step along the path is valid and trustworthy.

Customizing captive portal pages

Customizing captive portal pages

These pages are defined in replacement messages. Defaults are provided. In the web-based manager, you can modify the default messages in the SSID configuration by selecting Customize Portal Messages. Each SSID can have its own unique portal content.

The captive portal contains the following default web pages:

  • Login page—requests user credentials

Typical modifications for this page would be to change the logo and modify some of the text.

You can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters.

There is an exception to this rule. The line “Please enter your credentials to continue” is provided by the

%%QUESTION%% tag. You can replace this tag with text of your choice. Except for this item, you should not remove any tags because they may carry information that the FortiGate unit needs.

  • Login failed page—reports that the entered credentials were incorrect and enables the user to try again.

The Login failed page is similar to the Login page. It even contains the same login form. You can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters.

There is an exception to this rule. The line “Firewall authentication failed. Please try again.” is provided by the %%FAILED_MESSAGE%% tag. You can replace this tag with text of your choice. Except for this item, you should not remove any tags because they may carry information that the FortiGate unit needs.

  • Disclaimer page—is a statement of the legal responsibilities of the user and the host organization to which the user must agree before proceeding.(WiFi or SSL VPN only)
  • Declined disclaimer page—is displayed if the user does not agree to the statement on the Disclaimer page. Access is denied until the user agrees to the disclaimer.

 

Changing images in portal messages

You can replace the default Fortinet logo with your organization’s logo. First, import the logo file into the FortiGate unit and then modify the Login page code to reference your file.

 

To import a logo file:

1. Go to System > Config > Replacement Messages and select Manage Images.

2. Select Create New.

3. Enter a Name for the logo and select the appropriate Content Type.

The file must not exceed 24 Kilo bytes.

4. Select Browse, find your logo file and then select Open.

5. Select OK.

 

To specify the new logo in the replacement message:

1. Go to System > Network > Interfaces and edit the interface.

The Security Mode must be Captive Portal.

2. Select the portal message to edit.

  • In SSL VPN or WiFi interfaces, in Customize Portal Messages click the link to the portal messages that you want to edit.
  • In other interfaces, make sure that Customize Portal Messages is selected, select the adjacent Edit icon, then select the message that you want to edit.

3. In the HTML message text, find the %%IMAGE tag.

By default it specifies the Fortinet logo: %%IMAGE:logo_fw_auth%%

4. Change the image name to the one you provided for your logo.

The tag should now read, for example, %%IMAGE:mylogo%%

5. Select Save.

6. Select OK.

 

Modifying text in portal messages

Generally, you can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters. You should not remove any tags because they may carry information that the FortiGate unit needs. See the preceding section for any exceptions to this rule for particular pages.

 

To modify portal page text

1. Go to System > Network > Interfaces and edit the interface.

The SSID Security Mode must be Captive Portal.

2. Select the portal message to edit.

  • In SSL VPN or WiFi interfaces, in Customize Portal Messages click the link to the portal messages that you want to edit.
  • In other interfaces, make sure that Customize Portal Messages is selected, select the adjacent Edit icon, then select the message that you want to edit.

3. Edit the HTML message text, then select Save.

4. Select OK.

 

Configuring a captive portal

Configuring a captive portal

Captive portals are configured on network interfaces. On a physical (wired) network interface, you edit the interface configuration in System > Network > Interfaces and set Security Mode to Captive Portal. A WiFi interface does not exist until the WiFi SSID is created. You can configure a WiFi captive portal at the time that you create the SSID. Afterwards, the captive portal settings will also be available by editing the WiFi network interface in System > Network > Interfaces.

 

To configure a wired Captive Portal – web-based manager:

1. Go to System > Network > Interfaces and edit the interface to which the users connect.

2. In Security Mode select Captive Portal.

3. Enter

 

Authentication Portal                Local – portal hosted on the FortiGate unit.

Remote – enter FQDN or IP address of external portal.

User Groups                               Select permitted user groups or select Use Groups from Policies, which permits the groups specified in the security policy.

Use Groups from Policies is not available in WiFi captive portals.

Exempt List                                Select exempt lists whose members will not be subject to captive portal authentication.

Customize Portal

Messages

Enable, then select Edit. See Customizing captive portal pages on page 516.

4. Select OK.

 

To configure a WiFi Captive Portal – web-based manager:

1. Go to WiFi Controller > WiFi Network > SSID and create your SSID.

If the SSID already exists, you can edit the SSID or you can edit the WiFi interface in System > Network > Interfaces.

2. In Security Mode, select Captive Portal.

3. Enter

 

Portal Type                                 The portal can provide authentication and/or disclaimer, or perform user email address collection. See Introduction to Captive Portals on page 514.

Authentication Portal                Local – portal hosted on the FortiGate unit.

Remote – enter FQDN or IP address of external portal.

User Groups                               Select permitted user groups.

Exempt List                                Select exempt lists whose members will not be subject to captive portal authentication.

Customize Portal Messages     Click the link of the portal page that you want to modify. See “Captive portals” on page 516.

4. Select OK.

 

Exemption from the captive portal

A captive portal requires all users on the interface to authenticate. But some devices are not able to authenticate. You can create an exemption list of these devices. For example, a printer might need to access the Internet for firmware upgrades. Using the CLI, you can create an exemption list to exempt all printers from authentication.

config user security-exempt-list edit r_exempt

config rule edit 1

set devices printer end

end

Captive portals

Captive portals

A captive portal is a convenient way to authenticate web users on wired or WiFi networks. This section describes:

  • Introduction to Captive Portals
  • Configuring a captive portal
  • Customizing captive portal pages

 

Introduction to Captive Portals

You can authenticate your users on a web page that requests the user’s name and password. Until the user authenticates successfully, the authentication page is returned in response to any HTTP request. This is called a captive portal.

After successful authentication, the user accesses the requested URL and can access other web resources, as permitted by security policies. Optionally, the captive portal itself can allow web access to only the members of specified user group.

The captive portal can be hosted on the FortiGate unit or on an external authentication server. You can configure captive portal authentication on any network interface, including WiFi and VLAN interfaces.

When a captive portal is configured on a WiFi interface, the access point initially appears open. The wireless client can connect to the access point with no security credentials, but sees only the captive portal authentication page.

 

WiFi captive portal types:

  • Authentication — until the user enters valid credentials, no communication beyond the AP is permitted.
  • Disclaimer + Authentication — immediately after successful authentication, the portal presents the disclaimer page—an acceptable use policy or other legal statement—to which the user must agree before proceeding.
  • Disclaimer Only — the portal presents the disclaimer page—an acceptable use policy or other legal statement—to which the user must agree before proceeding. The authentication page is not presented.
  • Email Collection — the portal presents a page requesting the user’s email address, for the purpose of contacting the person in future. This is often used by businesses who provide free WiFi access to their customers. The authentication page is not presented.

Configuring authenticated access

Configuring authenticated access

When you have configured authentication servers, users, and user groups, you are ready to configure security policies and certain types of VPNs to require user authentication.

This section describes:

  • Authentication timeout
  • Password policy
  • Authentication protocols
  • Authentication in Captive Portals
  • Authentication in security policies
  • VPN authentication

 

Authentication timeout

An important feature of the security provided by authentication is that it is temporary—a user must re- authenticate after logging out. Also if a user is logged on and authenticated for an extended period of time, it is a good policy to have them re-authenticate at set periods. This ensures a user’s session is cannot be spoofed and used maliciously for extended periods of time — re-authentication will cut any spoof attempts short. Shorter timeout values are more secure.

 

Security authentication timeout

You set the security user authentication timeout to control how long an authenticated connection can be idle before the user must authenticate again. The maximum timeout is 1440 minutes (24 hours).

To set the security authentication timeout – web-based manager:

1. Go to User & Device > Authentication > Settings.

2. Enter the Authentication Timeout value in minutes.

The default authentication timeout is 5 minutes.

3. Select Apply.

 

SSL VPN authentication timeout

You set the SSL VPN user authentication timeout (Idle Timeout) to control how long an authenticated connection can be idle before the user must authenticate again. The maximum timeout is 259 200 seconds. The default timeout is 300 seconds.

 

To set the SSL VPN authentication timeout – web-based manager:

1. Go to VPN > SSL > Settings.

2. Under Idle Logout, make sure that Logout users when inactive for specified period is enabled and enter the Inactive For value (seconds).

3. Select Apply.

Managing Guest Access

Managing Guest Access

Visitors to your premises might need user accounts on your network for the duration of their stay. If you are hosting a large event such as a conference, you might need to create many such temporary accounts. The FortiOS Guest Management feature is designed for this purpose.

A guest user account User ID can be the user’s email address, a randomly generated string, or an ID that the administrator assigns. Similarly, the password can be administrator-assigned or randomly generated.

You can create many guest accounts at once using randomly-generated User IDs and passwords. This reduces administrator workload for large events.

 

Users view of guest access

1. The user receives an email, SMS message, or printout from a FortiOS administrator listing a User ID and password.

2. The user logs onto the network with the provided credentials.

3. After the expiry time, the credentials are no longer valid.

 

Administrators view of guest access

1. Create one or more guest user groups.

All members of the group have the same characteristics: type of User ID, type of password, information fields used, type and time of expiry.

2. Create guest accounts using Guest Management.

3. Use captive portal authentication and select the appropriate guest group.

 

Configuring guest user access

To set up guest user access, you need to create at least one guest user group and add guest user accounts. Optionally, you can create a guest management administrator whose only function is the creation of guest accounts in specific guest user groups. Otherwise, any administrator can do guest management.

 

Creating guest management administrators

To create a guest management administrator

1. Go to System > Admin > Administrators and create a regular administrator account.

For detailed information see the System Administration chapter.

2. Select Restrict to Provision Guest Accounts.

3. In Guest Groups, add the guest groups that this administrator manages.

 

Creating guest user groups

The guest group configuration determines the fields that are provided when you create a guest user account.

 

To create a guest user group:

1. Go to User & Device > User > User Groups and select Create New.

2. Enter the following information:

Name                                           Enter a name for the group.

Type                                            Guest

Viewing, editing and deleting user groups

Viewing, editing and deleting user groups

To view the list of FortiGate user groups, go to User & Device > User > User Groups.

 

Editing a user group

When editing a user group in the CLI you must set the type of group this will be — either a firewall group, a Fortinet Single Sign-On Service group (FSSO), a Radius based Single Sign-On Service group (RSSO), or a guest group. Once the type of group is set, and members are added you cannot change the group type without removing the members.

In the web-based manager, if you change the type of the group any members will be removed automatically.

 

To edit a user group – web-based manager:

1. Go to User & Device > User > User Groups.

2. Select the user group that you want to edit.

3. Select the Edit button.

4. Modify the user group as needed.

5. Select OK.

 

 

To edit a user group – CLI example:

This example adds user3 to Group1. Note that you must re-specify the full list of users:

config user group edit Group1

set group-type firewall

set member user2 user4 user3 end

 

 

Deleting a user group

Before you delete a user group, you must ensure there are no objects referring to, it such as security policies. If there are, you must remove those references before you are able to delete the user group.

 

To remove a user group – web-based manager:

1. Go to User & Device > User > User Groups.

2. Select the user group that you want to remove.

3. Select the Delete button.

4. Select OK.

 

 

To remove a user group – CLI example:

config user group delete Group2

end