| Solution |
When FortiGate is performing deep inspection, it intercepts and analyzes SSL/TLS encrypted traffic to inspect the content for potential threats. This process involves the following steps:
- SSL/TLS Handshake: When a client (e.g., a web browser) attempts to establish an SSL/TLS connection with a server (e.g., a website), the FortiGate acts as a proxy in the middle. It intercepts the connection request and initiates its SSL/TLS handshake with the client.
- Client Certificate Validation (Optional): If the server requires client authentication using client certificates, FortiGate may prompt the client to provide a client certificate. The FortiGate validates the client certificate and may proceed with the handshake.
- Server Certificate Validation: The server presents its SSL/TLS certificate during the handshake. The certificate contains the server's public key, its identity (common name, subject alternative names, etc.), the certificate's validity period, and the digital signature of the issuing Certificate Authority (CA).
- Certificate Chain Validation: The FortiGate verifies the authenticity of the server certificate by validating its chain of trust. It checks if the server certificate is signed by a trusted root CA certificate in its certificate store. If the certificate chain is valid, FortiGate knows that the server's identity is legitimate.
- Certificate Revocation Check: The FortiGate checks the certificate revocation status using Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) responses. This step ensures that the server certificate has not been revoked by the issuing CA before its expiration date.
- Certificate Inspection and Decryption: Once FortiGate establishes the SSL/TLS connection with the client and validates the server certificate, it decrypts the encrypted traffic from the client. This decryption allows the FortiGate to analyze the content of the encrypted communication.
- Deep Inspection: With the SSL/TLS traffic decrypted, FortiGate performs deep packet inspection (DPI) on the encrypted content. It analyzes the data, including URLs, file attachments, and other potential threats. This inspection enables the FortiGate to detect and block malicious content, viruses, malware, or any policy-violating data.
- Content Filtering and Threat Detection: After inspection, the FortiGate enforces security policies based on the content's nature. It may apply antivirus scanning, web filtering, intrusion prevention, and other security services to protect the client from potential threats.
- Re-encryption and Forwarding: After deep inspection and applying security policies, if the content is deemed safe, the FortiGate re-encrypts the traffic using the server's original certificate and forwards it to the destination server on behalf of the client.
How Certificate Chain Validation is done by the FortiGate.
Certificate chain validation is a critical step in the SSL/TLS handshake process that ensures the authenticity and integrity of the server's SSL/TLS certificate presented during the connection. FortiGate performs certificate chain validation using the following steps:
- Receive Server Certificate: During the SSL/TLS handshake, the server presents its SSL/TLS certificate to the FortiGate as part of the ServerHello message.
- Extract Certificate Information: FortiGate extracts the server certificate from the ServerHello message and obtains important information from it, such as the server's public key, the certificate's validity period, and the digital signature.
- Check Certificate Validity Period: FortiGate checks if the current date and time fall within the validity period specified in the server certificate. If the certificate has expired or is not yet valid, the chain validation process fails.
- Check Certificate Signature: FortiGate verifies the digital signature on the server certificate using the public key of the issuing Certificate Authority (CA). To do this, FortiGate must have the CA certificate that signed the server certificate in its certificate store.
- Certificate Chain Building: If the server certificate is signed by an intermediate CA (or multiple intermediate CAs), FortiGate proceeds to build the certificate chain. This involves looking for the intermediate CA certificates that are needed to link the server certificate to a trusted root CA certificate.
- Check Trust Anchor: FortiGate compares the issuer (CA) of the server certificate to its list of trusted root CA certificates. The trusted root CA certificates are pre-installed on the FortiGate and serve as the anchors of trust.
- Chain Verification: FortiGate then verifies the entire certificate chain from the server certificate up to the root CA certificate. It checks the signatures and validity periods of each intermediate CA certificate until it reaches a trusted root CA certificate.
- Certificate Revocation Check: As part of the chain validation process, FortiGate may also check the certificate revocation status using Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) responses. This step ensures that none of the certificates in the chain have been revoked by their respective issuing CAs.
- Chain Validation Result: Based on the result of the chain validation process, FortiGate determines whether the server certificate is valid, and thus, whether the SSL/TLS connection should proceed.
Below is a FNBAM debug output for www.fortinet.com where the certificate is from DigiCert;
[2364] handle_req-Rcvd auth_cert req id=24, len=1098, opt=0 <----- FNBAM receives a request.
[983] __cert_auth_ctx_init-req_id=24, opt=0
[103] __cert_chg_st- 'Init' <----- Initiate chain validation.
[156] fnbamd_cert_load_certs_from_req-2 cert(s) in req.
[669] __cert_init-req_id=24
[718] __cert_build_chain-req_id=24
[273] fnbamd_chain_build-Chain discovery, opt 0x13, cur total 1
[291] fnbamd_chain_build-Following depth 0
[320] fnbamd_chain_build-Extend chain by system trust store. (no luck)
[374] fnbamd_chain_build-Extend chain by peer-provided certs. (good)
[291] fnbamd_chain_build-Following depth 1
[326] fnbamd_chain_build-Extend chain by system trust store. (good: 'DigiCert_Global_Root_G2') <----- CA certificate is in a trusted store.
[291] fnbamd_chain_build-Following depth 2//
[305] fnbamd_chain_build-Self-sign detected. <----- Self-signed CA certificate detected.
[99] __cert_chg_st- 'Init' -> 'Validation'
[840] __cert_verify-req_id=24
[841] __cert_verify-Chain is complete. <----- Chain verification completed.
[486] fnbamd_cert_verify-Chain number:3
[500] fnbamd_cert_verify-Following cert chain depth 0
[500] fnbamd_cert_verify-Following cert chain depth 1
[573] fnbamd_cert_verify-Issuer found: DigiCert_Global_Root_G2 (SSL_DPI opt 1)
[500] fnbamd_cert_verify-Following cert chain depth 2
[689] fnbamd_cert_check_group_list-Will match any!
[191] __get_default_ocsp_ctx-def_ocsp_ctx=(nil), no_ocsp_query=0, ocsp_enabled=0
[876] __cert_verify_do_next-req_id=24
[99] __cert_chg_st- 'Validation' -> 'Done' <----- Validation completed.
[921] __cert_done-req_id=24
[1635] fnbamd_auth_session_done-Session done, id=24
[966] __fnbamd_cert_auth_run-Exit, req_id=24
[1672] create_auth_cert_session-fnbamd_cert_auth_init returns 0, id=24
[1591] auth_cert_success-id=24
[1068] fnbamd_cert_auth_copy_cert_status-req_id=24
[884] fnbamd_cert_check_matched_groups-checking group ANY
[895] fnbamd_cert_check_matched_groups-matched
[1107] fnbamd_cert_auth_copy_cert_status-Leaf cert status is unchecked.
[1124] fnbamd_cert_auth_copy_cert_status-Issuer of cert depth 0 is not detected in CMDB.
[1195] fnbamd_cert_auth_copy_cert_status-Cert st 2c0, req_id=24
[209] fnbamd_comm_send_result-Sending result 0 (nid 672) for req 24, len=2538
[1536] destroy_auth_cert_session-id=24
[1041] fnbamd_cert_auth_uninit-req_id=24
|
