Technical Tip: FortiGate PKI certificate usage & troubleshooting guide

Rudresh_Veerappaji · ‎11-21-2024

Description

This article describes the various use cases that PKI certificates are used for in the FortiGate, how to enable the certificates for specific features with examples, and the priority order in which the certificate configurations are applied - which would be helpful for troubleshooting certificate related issues. A deep dive (with WAD debugs) for an example use case to verify which CA certificate is used for proxy certificate signings is also covered in this article.

Scope

FortiGate, PKI.

Solution

Several security use cases require the use of PKI certificates, and can be configured in the FortiGate under corresponding features. The type and order of these configurations will dictate how the certificates are used by the individual features, hence it is important to understand the various locations where certificate mappings can be configured in the FortiGate, and the priority in which the certificates are chosen for authentication/inspection etc. This would also be useful when troubleshooting issues wherein the intended certificate does not seem to be used for a particular feature, to analyze what other config could be overriding the certificate mappings and how to fix the issue.

Two main categories of use cases can be considered for the purposes of this article, namely 'VPN use cases' which deals with using certificates for VPN authentications (IPSec and SSL), and the other 'Non-VPN use cases' which deal with various other use cases like captive portal authentication, Firewall policy - SSL inspection, webfilter authentication, etc which are described with examples in the next section.

VPN use cases.

This section covers the certificate mappings for basic VPN use cases namely the IPSec VPN and SSL VPN authentications.

1.1. IPSec VPN with certificate authentication.

The 'set certificate' setting in the IPSec interface maps the certificate to be used by this FortiGate to authenticate itself to the VPN peer during the IPSec VPN session setup.

config vpn ipsec phase1-interface
edit "S2S-VPN-PKI"

. . .
set authmethod signature
set certificate "ACME-FGT-VPN-certificate" <----- Cert used by this FortiGate for authenticating itself to the VPN peer.

set peer "PKI-S2S_peer" <----- Accept certificates from peer if it is signed by this CA certificate.

1.2 SSL VPN Remote access.

The 'set servercert' setting in the global VPN SSL settings maps the certificate to be used as server certificate by FortiGate for the SSL VPN setup with the Remote access SSL VPN client.

config vpn ssl settings

set servercert "ACME-FGT-SSL-Server-certificate" <----- This is the server certificate that will be used for SSL VPN connections from clients.

Non-VPN use cases.

This section covers the various authentication use cases where the type and order of the configurations becomes important to ensure the intended certificate is used for the corresponding feature. Before getting to each of these use cases in more detail, it is necessary to first understand the difference between the auth-ca-cert and auth-cert setting in the 'config user setting' where the global user authentication settings are configured.

auth-ca-cert vs auth-cert:

'auth-ca-cert' is the CA certificate that is used for signing the inspected (man in the middle) sessions by FortiGate, and auth-cert will be used as server certificate for non-signing server sessions (used only if auth-ca-cert is not configured).
Hostname will be obtained from client hello and used to resign the certificate by auth-ca-cert. If hostname is not present, the destination IP address will be used instead.

config user setting

set auth-cert "ACME-Cert" <----- This certificate will be used as a server certificate for non-signing server sessions.
set auth-ca-cert "ACME-CA-Cert" <----- This CA certificate will be used to re-sign all server certificates.
set auth-secure-http enable

end

When auth-ca-cert is enabled on the FortiGate, all server certificates will be re-signed by this CA (even when auth-cert with a different cert is configured). So if the requirement is to use just one common CA cert for all authentication use cases, then enable auth-ca-cert globally under 'config user setting' as a simple solution. It will override any other auth-cert config in the FortiGate and has the top priority when it comes to what server certificate to present to end users.

If auth-ca-cert is not configured, then the following settings are taken into consideration while choosing the certificate with a descending priority order:

1. Captive portal interface auth cert.

2. Firewall policy auth cert.

3. Webfilter authenticate

4. User setting auth cert.

5. System global auth cert.

6. web-proxy global.

In the next section, the above use cases are discussed with examples.

2.1 Captive portal interface authentication.

Captive portal can be configured on any network interface - physical, VLAN or Wi-Fi interfaces, by enabling security-mode to 'captive portal'. The configuration 'set auth-cert' is used to define which certificate is to be used for captive portal authentication page that is displayed to the user.

config system interface

edit "VLAN-60-Guest"

set description "Guest Wifi"
set security-mode captive-portal
set auth-cert "ACME-Captive-portal-Cert" <----- This certificate will be used for captive portal login page.
set auth-portal-addr "guestaccess.acme-portal.example.com"

...

2.2 Firewall policy.

When SSL inspection is enabled for a Firewall policy, the CA certificate to be used for the deep/certificate inspection is defined under the corresponding security profile, as shown in the example below:

FortiGate $ show firewall policy

config firewall policy

edit 11

. . .
set name "Allow-lan-to-wan"

set ssl-ssh-profile "custom-deep-inspection"

FortiGate $ show firewall ssl-ssh-profile

config firewall ssl-ssh-profile

edit "custom-deep-inspection"

. . .

set caname "ACME-SubCA-For-SSL-Inspection" <----- This is the CA certificate used for SSL inspection for the corresponding firewall policy.
next

end

2.3 Webfilter authentication.

One of the possible actions for category based web filter is 'Authenticate', wherein the user is prompted for credentials to access specific categories. The authentication page shown for this use case will need a certificate, which is the one from the corresponding SSL inspection security profile (associated with this firewall policy) if it is enabled, and if it is not - then it will use the certificate defined in the web-proxy global settings (described in section 1.6) below.

config webfilter profile

edit "AKME-webfilter-1"

set feature-set proxy

config ftgd-wf

config filters

edit 35

set category 37

set action authenticate <----- Enables authentication requirement for the user when accessing this category.

set auth-usr-grp "Local-accounts" <----- User groups that are allowed to authenticate for this category.

end

2.4 User settings.

Most of the user authentication settings are available for configuration under the 'config user setting'. The main settings relevant to this article are the auth-cert and auth-ca-cert, which were discussed earlier in the article.

FortiGate $ show user setting

config user setting

set auth-cert "AKME-cert" <----- This is the certificate used for authentication login page shown to users, if auth-ca-cert is not configured.

set auth-ca-cert "AKME-CA-cert" <----- If auth-ca-cert is configured, it takes priority over all other cert configs in the FortiGate.

set auth-secure-http enable

end

To enable authentication for users when connecting to the network through FortiGate, enable 'set groups' or 'set users' under the firewall policy as shown in the example below. This will trigger an authentication redirection to a browser when a user tries to connect to the network. The certificate that will be used for this authentication page is the 'auth-ca-cert' (or 'auth-cert' if the former is not configured) setting defined in 'config user setting'.

config firewall policy

edit 11
set name "Allow-lan-to-wan"
. . .
set groups "Local-accounts" <----- Enables user authentication for groups, lists the groups (of users) that can authenticate with this policy.

set users "internal-user-1" <----- Enables user authentication individually per user, lists the names of individual users that can authenticate with this policy.
next

end

2.5 System global settings.

The certificate that is used by FortiGate for HTTPS connections to it's local interface (like GUI access for management) is controlled by 'set admin-server-cert' under 'config system global'. The auth-cert setting here is used for user authentication (described in section 1.4) - if there is no auth-cert configured in 'config user settings'.

FortiGate $ show sys global

config system global

. . .
set admin-server-cert "RootCA-Fortinet-Lab" <----- Server certificate that the FortiGate uses for HTTPS administrative connections.
set auth-cert "ACME-SSL-Cert" <----- Server certificate that the FortiGate uses for HTTPS firewall authentication connections, and it is used if auth-cert under 'config user setting' is not configured.

2.6 Web-proxy global settings.

The 'ssl-ca-cert' in the web-proxy global settings is the fallback certificate used if SSL inspection or auth certificates are not configured in any of the previous settings.

config web-proxy global

set ssl-ca-cert "Fortinet_CA_SSL" <----- This is the SSL signing certificate used as a fallback option if no other certificate mapping is configured.

end

Verify which certificate is being used for a feature.

While the previous section explains the logic behind which certificate is selected for a particular feature as per configuration, following is the list of debugs that can be enabled (enable only specific debugs depending on which feature is in use, apply with specific filters and preferably in a change window) to verify which certificate is ultimately used for a task (proxy signing, block page cert, captive portal, etc) and troubleshoot further if it is not using the correct cert as expected or any other certificate issues.

diagnose debug application authd -1 <----- For general authentication debugs.

diagnose debug application https -1 <----- HTTPS debugs, shows server cert used for admin interface.

diagnose debug application ike -1 <----- IKEv1/IKEv2/IPSec VPN debugs, shows certs used for auth.

diagnose debug application sslvpn -1 <----- SSL VPN debugs, shows cert used for SSL handshakes.

diagnose debug application foauthd -1 <----- When webfilter override is enabled.

diagnose debug app fnbamd -1 <----- When using Remote auth servers (LDAP, Radius, MFA, etc).
diagnose wad debug enable <> <----- For proxy related debugs.

diagnose debug application samld -1 <----- For SAML-based authentications.

diagnose debug console timestamp enable <----- To add timestamps to debugs.

diagnose debug info <----- Review the debug settings before enabling.

diagnose debug enable <----- Enable the debugs.

execute log display <----- Review logs as well for cert issues, use log filters (VPN, SSL, etc).

Deep dive with debugs for an example use case.

Here is a deep dive on the debugs for an example scenario - for a Client to Server session matching a firewall policy with SSL deep inspection which has a custom CA certificate configured as per section 2.2 for proxy certificate signing:

IP Addresses used in the example:

IP address	Description
192.168.10.2	Client IP address
10.9.11.26	FortiGate WAN interface IP address
a.b.c.d	Github.com server IP address (masked) that client is trying to access with a browser

Topology:

Client(browser)192.168.10.2------192.168.10.1(LAN)FortiGate(WAN)10.9.11.26-------Server(github/a.b.c.d)

Config snippet:

config firewall ssl-ssh-profile
edit custom-deep-inspection
. . .
set caname acmeCAcert <----- This is the CA cert that will be used for signing proxy certs as shown in debugs in the next section.
next
end

Debugs enabled for this use case:

diagnose wad debug enable all
diagnose debug application authd -1
diagnose debug application foauthd -1
diagnose debug enable

Relevant debug entries (not the full output for brevity) with explanations:

[I]13:22:22.454950 [p:2706] wad_accept :2409 redirect 70 accepted 192.168.10.2:56502 -> a.b.c.d:443 on 104
[I]13:22:22.454969 [p:2706] wad_tcp_port_learn_v4_session :125 Redir session state=0x102302 state2=0x0 state_ext=0x0.

The debug snippet above indicates an incoming connection request from client browser to reach out to Github.com IP address is accepted and redirected to WAD, for proxying and deep SSL inspection as per the configuration.

[I]13:22:22.454996 [p:2706][s:141985] wad_tcp_port_alloc :1483 alloc tcp_port=0x7f5eb861d190
[V]13:22:22.455019 [p:2706][s:141985] wad_tcp_port_bind :576 tcp_port=0x7f5eb861d190 src ip:192.168.10.2 is bind, create sess:0
[V]13:22:22.455021 [p:2706][s:141985] wad_tcp_port_connect_with_fd :2236 oif =3, fwd_oif=0 src_addr_unkown=0
[I]13:22:22.455037 [p:2706][s:141985] wad_tcp_port_connect_with_fd :2280 TCP port=0x7f5eb861d190 sock=107 vrf=0 connecting 10.9.11.26:56502->a.b.c.d:443

The debug snippet above indicates FortiGate is creating a proxy connection (TCP) from its WAN IP address 10.9.11.26 to the server (a.b.c.d).

[I]13:22:22.455041 [p:2706][s:141985] wad_tcp_port_alloc :1483 alloc tcp_port=0x7f5eb861d2d8
[I]13:22:22.455061 [p:2706] wad_tcp_port_put :641 free tcp_port=0x7f5eb861d2d8
[I]13:22:22.478134 [p:2706][s:141985] wad_tcp_port_on_connect :2054 TCP connection 0x7f5eb861d190 fd=107 connected 10.9.11.26:56502->a.b.c.d:443
[I]13:22:22.478164 [p:2706][s:141985] wad_ssl_port_open :20832 wsp=0x7f5eb861d190/7 making SSL port
[V]13:22:22.478172 [p:2706][s:141985] wad_ssl_negotiate_make :2392 nego=0x7f5eb8495960
[V]13:22:22.478174 [p:2706][s:141985] wad_ssl_port_update_cert_mode :5673 nego=0x7f5eb8495960 ca=0x7f5eb4f94160 name=acmeCAcert

The debug snippet above indicates FortiGate will be using the CA signing certificate indicated here, name=acmeCAcert to create and sign both the client proxy certificate to share with the Server, as well as to create and sign the server proxy certificate to share with the client later.

[I]13:22:22.478183 [p:2706][s:141985] wad_ssl_port_open :21125 wsp=0x7f5eb85bf048/7 SSL-port open succ type=7 port=0x7f5eb861d190 vd=0 svr=140.82.113.4:443: succ
[I]13:22:22.478184 [p:2706][s:141985] wad_ssl_port_open :20832 wsp=0x7f5eb861d048/6 making SSL port

SSL handshake initiation for the proxy connection from FortiGate to Server.

[I]13:22:22.494638 [p:2706][s:141985] wad_ssl_port_get_client_hello_sni :7853 wsp(0x7f5eb85bf3f0/6) get clt_hello sni(github.com), copied: 1
[V]13:22:22.494665 [p:2706][s:141985] wad_url_fetch_cate2 :1499 host=github.com ip=140.82.113.4
[I]13:22:22.494690 [p:2706][s:141985] wad_ssl_check_urlf_and_exempt :5376 wsp=0x7f5eb85bf3f0/6 ssl.deep_scan=1/1/0 ssl_proc=ducsbe2n host=github.com ip=0 rating=1 exempt=x_none(SNI.x_none same unknown.x_none):
[I]13:22:22.494711 [p:2706][s:141985] wad_ssl_url_filter_check_local :3721 nego 0x7f5eb8495658 webf=web-filter-test host=github.com vd=root id=0 dst=a.b.c.d

Debug snippet above indicates FortiGate checking the webfilter rules for the connection to server (github.com) to decide whether to allow, block, warn or any other action.

[V]13:22:22.494715 [p:2706][s:141985] wad_url_fetch_cate2 :1499 host=github.com ip=140.82.113.4
[I]13:22:22.494972 [p:2706][s:141985] wad_send_url_request_new :1585 (0-Ok): cnt=1 id=288() url='github.com'[a.b.c.d] from=192.168.10.2 url-src=SNI cate=255 tasks=Rat
[I]13:22:22.544600 [p:2706] wad_url_filter_dump_result :224 wad_url_filter_on_read(dump) id=288 state=verdict type=req_https has_cat=0[0] log=0 result: id=288 log=0 cate=52(52/52) flags=00000102 action=ftgd-monitor warn_domain=0 warn_session=0
[I]13:22:22.544622 [p:2706][s:141985] wad_url_choose_cate :2207 cate=52 (ftgd) url-cates=[52,]; url=[ # 52,],ip=[ # 52,]; conf webfilter 'web-filter-test':[140,141,96,98,99,64,65,66,67,83,86,88,90,91,36,37,57,59,61,62,6]
[I]13:22:22.544627 [p:2706][s:141985] wad_url_filter_dump_result :224 wad_url_filter_check_url_filter_on_result(dump) id=288 state=done type=req_https has_cat=1[52] log=0 result: id=0 log=0 cate=52(0/0) flags=00000000 action=ftgd-allow warn_domain=0 warn_session=0
[I]13:22:22.544661 [p:2706][s:141985] wad_url_choose_cate :2207 cate=52 (ftgd) url-cates=[52,]; url=[ # 52,],ip=[ # 52,]; conf sslexempt_rating '':[87,33,31,]
[I]13:22:22.544664 [p:2706][s:141985] wad_ssl_proxy_srv_continue_client_hello:8388 wsp=0x7f5eb85bf3f0/6 ssl_proc=ducsbe2n bypass-chk=1 sni=1 cic=0 tls1.3=1
[V]13:22:22.544668 [p:2706][s:141985] wad_ssl_bypass_cache_find :21394 Try to find (a.b.c.d, github.com) in ssl-bypass cache.
[V]13:22:22.544674 [p:2706][s:141985] wad_ssl_port_c2p_validate_psk :7437 wsp=0x7f5eb85bf3f0/6 id=(nil) modes=0
[I]13:22:22.544677 [p:2706][s:141985] wad_ssl_port_client_hello_validate_psk:7615 wsp(0x7f5eb85bf3f0/6) verified PSK: 0
SESSION-ID: 303da202a9e5375a8bd7ad8f1b944beab7673ceb67ab1d92cab2ba2871465409
[V]13:22:22.544682 [p:2706][s:141985] wad_ssl_proxy_find_session :1738 can't find the session!
[I]13:22:22.544684 [p:2706][s:141985] wad_ssl_proxy_srv_continue_fwd_client_hello:8302 sp=0x7f5eb85bf3f0/6 start handshake with server. changed_ch=1
[V]13:22:22.544692 [p:2706][s:141985] wad_ssl_proxy_caps_ciphers :14205 sp=0x7f5eb85bf048/7
[I]13:22:22.588814 [p:2706][s:141985] wad_ssl_proxy_caps_on_srv_certs :13225 sp=0x7f5eb85bf048/7 find cert=(nil)
[I]13:22:22.588946 [p:2706][s:141985] __wad_ssl_cert_open_cert :663 https server uses key_len 256
[I]13:22:22.589022 [p:2706][s:141985] wad_ssl_cert_sni_check2 :2459 sni=github.com, matched name=github.com
[V]13:22:22.589092 [p:2706][s:141985] wad_ssl_proxy_caps_clt_on_cert_verify:14552 wsp(0x7f5eb85bf048/7) CertificateVerify scheme 0403
[I]13:22:22.592696 [p:2706][s:141985] wad_ssl_common_on_handshake_done :10057 sp=0x7f5eb85bf048/7 SSL handshake done! cipher-num=0x1301

SSL handshake complete for the session between FortiGate to Server (github.com).

[I]13:22:22.711312 [p:2706][s:141985] wad_ssl_cert_get_auth_status :2373 cert:status=fnbam result=good stale=0 ocsp:status=good reason=unspecified cfg:expired=2 revoked=2 timeout=1 failure=2 untrusted=1
[I]13:22:22.711332 [p:2706][s:141985] wad_ssl_port_on_cert_notify :4153 sp=0x7f5eb85bf048/7 cert auth: fnbam resp=success
[V]13:22:22.711340 [p:2706][s:141985] wad_ssl_cic_oid_gen :560 vfid=0 sni=github.com 10.9.11.26->a.b.c.d
[V]13:22:22.711348 [p:2706][s:141985] wad_ssl_cic_client_add :2326 oid=14868187111401480566
[I]13:22:22.711357 [p:2706][s:141985] wad_ssl_cic_core_dump_item :221 cic-core add new item host='github.com' age=1800-0 oid=14868187111401480566 sni-mismatch=0 auth result: status=fnbam cert_status=good
[I]13:22:22.711382 [p:2706][s:141985] wad_ssl_proxy_clt_add_cic_cache :4103 wsp=0x7f5eb85bf048/7 complete=1 staled=0 sni=(1) host=github.com add cert-result succ: auth result: status=fnbam cert_status=good
[I]13:22:22.711389 [p:2706][s:141985] wad_ssl_cert_get_auth_status :2373 cert:status=fnbam result=good stale=0 ocsp:status=good reason=unspecified cfg:expired=2 revoked=2 timeout=1 failure=2 untrusted=1
[I]13:22:22.711391 [p:2706][s:141985] wad_ssl_proxy_generate_forged_cert:8973 sp=0x7f5eb85bf048/7 cert auth success
[I]13:22:22.711391 [p:2706][s:141985] wad_ssl_proxy_generate_forged_cert:8973 sp=0x7f5eb85bf048/7 cert auth success
[I]13:22:22.711405 [p:2706][s:141985] wad_ssl_proxy_cert_create_picker :2146 wsp(0x7f5eb85bf048/7) got key type(3) with ss(1027)

The debug snippet above indicates FortiGate is generating a server proxy certificate to send to the client for the client-FortiGate proxy connection, the CA used to sign this certificate is the one tagged earlier (name=acmeCAcert) at the beginning of this session.

[I]13:22:22.711546 [p:2706][s:141985] wad_cert_picker_get_subject :2504 subject=/CN=github.com
[I]13:22:22.711674 [p:2706][s:141985] wad_ssl_cert_factory_product_make :2923 raw_cert 0x7f5eb7fa90f8, ksize = 256, key_type = 3, priv_key = 0x7f5eb4e58268
[I]13:22:22.712246 [p:2706][s:141985] wad_ssl_cert_storage_add_product :2349 n_certs=46 mem_certs=6254 subject=/CN=github.com
[V]13:22:22.712248 [p:2706][s:141985] wad_ssl_cert_storage_add_product :2358 add cert product=0x7f5eb978d1c8 to hash table index=839
[I]13:22:22.712250 [p:2706][s:141985] wad_ssl_proxy_generate_certificate_status:9080 wsp=0x7f5eb85bf048/7 ocsp (nil).!
[I]13:22:22.712257 [p:2706][s:141985] wad_ssl_proxy_set_13_cipher :3479 wsp=0x7f5eb85bf048/7 cipher 1301 KeyShare.Group 29
[I]13:22:22.712262 [p:2706][s:141985] wad_ssl_proxy_set_13_resign_cert :3426 wsp=0x7f5eb85bf048/7 signature-scheme 403

FortiGate server proxy certificate signing is complete, and the next will continue the SSL handshake with the client browser.

[I]13:22:22.712264 [p:2706][s:141985] wad_ssl_proxy_resume_c2p_handshake:3981 wsp(0x7f5eb85bf048/7) continue client side nego ret=1
[I]13:22:22.712266 [p:2706][s:141985] wad_ssl_proxy_client_hello_accept :3941 wsp(0x7f5eb85bf048/7) accepted ch! wst=(nil)
[V]13:22:22.712270 [p:2706][s:141985] wad_key_share_bucket_get_entry :172 key_share 0x7f5eb9694df8 g=29 use_cnt=84 holding=1 reuseable 1
[V]13:22:22.712306 [p:2706][s:141985] wad_ssl_port_caps_on_enc_start :15025 sp=0x7f5eb85bf3f0/6 enc start 0x7f5eb8436988 type 22 ver 0303 len 122 (02 00 00 76 03 03 ca d6 e3 a7 b4 d6 ff 6f b6 d5 35 57 70 )
[V]13:22:22.712318 [p:2706][s:141985] wad_ssl_port_caps_on_enc_done :15052 sp=0x7f5eb85bf3f0/6 enc done 0x7f5eb8436988 type 22 ver 0303 status 0 len 127 (16 03 03 00 7a 02 00 00 76 03 03 ca d6 e3 a7 b4 )
[V]13:22:22.712320 [p:2706][s:141985] wad_ssl_sock_port_fts_in_write :15793 sp=0x7f5eb85bf3f0/6 start=0 len=127
[V]13:22:22.712324 [p:2706][s:141985] wad_ssl_sock_port_out_ops_sync :17185 sp=0x7f5eb85bf3f0/6 state=1 fts-input=127 proxy-input=0
[V]13:22:22.712328 [p:2706][s:141985] wad_ssl_sock_port_exec_dn_forward :16945 sp=0x7f5eb85bf3f0/6 ib-len=127
[V]13:22:22.712334 [p:2706][s:141985] wad_tcp_port_out_read_sync :963 tcp_port(0x7f5eb861d048) sync 127
[V]13:22:22.712339 [p:2706][s:141985] wad_ssl_sock_port_fts_in_write :15793 sp=0x7f5eb85bf3f0/6 start=0 len=6
[V]13:22:22.712340 [p:2706][s:141985] wad_ssl_sock_port_out_ops_sync :17185 sp=0x7f5eb85bf3f0/6 state=1 fts-input=6 proxy-input=0
[V]13:22:22.712341 [p:2706][s:141985] wad_ssl_sock_port_exec_dn_forward :16945 sp=0x7f5eb85bf3f0/6 ib-len=6

The debug entries above indicate successful proxy SSL handshakes for both ends - client and server - and the application traffic going through the session.

[I]13:22:22.804615 [p:2706][s:141985] wad_ssl_app_port_fts_in_close :17477 sp=0x7f5eb85bf3f0/6 recv close request from fts close-type=0 closed=0
[I]13:22:22.804902 [p:2706] wad_tcp_port_put :641 free tcp_port=0x7f5eb861d048
[I]13:22:22.804905 [p:2706] wad_tcp_port_alloc :1483 alloc tcp_port=0x7f5eb861d048

The session is closed gracefully upon a close request from the client.

Related documents:

Technical Tip: FortiGate PKI certificate usage & troubleshooting guide

You are leaving our website