FAQ

How do I detect which cipher suite is used for HTTPS connections?

Use sniffing (packet capture) to capture SSL/ TLS traffic and view the “Server hello” message, which includes cipher suite information.

For more HTTPS troubleshooting information, see "Supported cipher suites & protocol versions" and "Checking the SSL/TLS handshake & encryption" in FortiWeb Administration Guide

How can I strengthen my SSL configuration?

The following configuration changes can make SSL more effective in preventing attacks and can improve your website's score for third-party testing tools (for example, the SSL server test provided by Qualys SSL Labs).

Which configuration changes you make depends on your environment. For example, some older clients do not support SHA256.

• For your website certificate, do the following:

  • If it uses the SHA1 hashtag function, replace it with one that uses SHA256.

  • Ensure that its key size is 2048-bit.

• For the server policy (Reverse Proxy mode) or server pool member configuration (True Transparent Proxy mode), specify the following values in the advanced SSL settings:

  • Select Add HSTS Header, and then for Max. Age, enter 15552000.

  • For Supported SSL Protocols, disable SSL 3.0.

  • For SSL/TLS Encryption Level, select High.

  • For Enable Perfect Forward Secrecy, select Yes.

  • Select Disable Client-Initiated SSL Renegotiation.

For details, see Configuring a server policy on in FortiWeb Administration Guide.

Use the following CLI command to set the Diffie-Hellman key exchange parameters to 2048 or greater:

config system global

set dh-params 2048

The command is available in FortiWeb 5.3.6 and higher releases. For additional information on using CLI commands, see the FortiWeb CLI Reference:

HTTPS://docs.fortinet.com/product/fortiweb/

Does FortiWeb support partial-chain verification?

On 7.0.1 and previous builds, FortiWeb needs the full certificate chain (RootCA + SubCA) in the CA-group to validate the client certificate. If only intermediate CA is included in the CA Group, client verification will fail.

7.0.2 supports partial-chain verification by enabling below options via CLI:

• set trust-anchor to "enable" for a CA group

• set parial-chain to "enable" in the certificate verify rule

FortiWeb # show system certificate ca-group

config system certificate ca-group

edit "CA_GP_01"

config members

edit 1

set name subCA_Group_01

set trust-anchor enable

next

end

next

end

FortiWeb # show system certificate verify

config system certificate verify

edit "Client_Cert_Verify_01"

set ca subCA_Group_01

set particle-chain enable

next

end

How to troubleshoot a LetsEncrypt certificate obtaining failure?

If Letsencrypt is configured for a server policy, but system fails to obtain a certificate, you can follow these steps for troubleshooting:

1. Check prerequisites for Letsencrypt:

   • The DNS entry has been mapped to your domain name with FortiWeb's VIP address.

   • If multiple SANs (Subject Alternative Name) are added, make sure that all domains are mapped to the same public IP address (also FortiWeb's VIP).

     From 7.0.2, FortiWeb supports requesting a LetsEncrypt certificate with multiple SAN (Subject Alternative Name). You can add SAN via Server Objects > Certificates > Letsencrypt > Create New.

   • Do not block requests from United States in IP Protection > Geo IP Block, otherwise FortiWeb can't retrieve certificates from Let's Encrypt.

2. Check Letsencrypt related configuration on FortiWeb:

   • Make sure that port 80 is enabled, because Let's Encrypt sends HTTP requests to FortiWeb in order to validate the ownership of the domain name:

     • In RP mode, make sure to select HTTP service when configuring server policy.

     • In TTP mode, the back-end server which uses Letsencrypt certificate should have port 80 enabled.

   • If you select the Letsencrypt certificate and also enable Redirect HTTP to HTTPS, make sure that both domain.com and domain.com:443 are added as the accepted hosts in Protected Hostnames settings.
     

   • If a server policy enables HTTP Content Routing, make sure the match conditions match both domain.com and domain.com:443.
     

     Notes: Before 7.2.0, we only the HTTP-01 validation method. For 7.2.0, support of DNS-01 and TLS-ALPN-01 are added to address the above limitation.
     

3. Check event logs for success or failure events.

   Both successful and failed issue processes will generate at least one event log. You can right click the log to check detailed information.

   Certificate renewal will also generate event logs.

   

   Sample for detailed event log info:
   

4. Check more details in diagnose logs:

   For 7.0.2 and previous builds, you just need to enable below commands for diagnose logs:

   diagnose debug application acmed 7

   diagnose debug enable

   Sample for a certificate issuing failure due to DNS search failed:

   (acme_log_err_event_process_inner_json : 583)acme_log_err_event_process_inner_json: type = urn:ietf:params:acme:error:dns, detail = DNS problem: NXDOMAIN looking up A for sports.fwbtestgslb.com - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for sports.fwbtestgslb.com - check that a DNS record exists for this domain

   (acme_post : 742)acme_post: return code 200, json=

   (authorize : 1025)challenge https://acme-v02.api.letsencrypt.org/acme/chall-v3/148263779557/UU140g failed with status invalid

   (acme_error : 276)the server reported the following error:

   (authorize : 1039)running /etc/acme/acme.sh failed http-01 sports.fwbtestgslb.com xBEJLu4bsEHTIf_3LVvY1_VwWLTdovJmHMicWx5lPNE xBEJLu4bsEHTIf_3LVvY1_VwWLTdovJmHMicWx5lPNE.i9Tp-bb8fw4CsxC7QJfuRYMDQv-251EzsYgn3o3DQ6s

   (cert_issue : 1328)failed to authorize order at https://acme-v02.api.letsencrypt.org/acme/order/643342336/121299792817

   (acme_cert_valid_and_issue : 1669)/etc/acme/try.fwbtestgslb.com cert issue failed

   (cert_load : 1282)/etc/acme/try.fwbtestgslb.com/cert.pem does not exist

   (acme_update_cert : 1127)acme_update_cert:1127: update CMDB entry try.fwbtestgslb.com status to 7

   Sample for a certificate issuing failure due to reaching the max retry limitation:

   (acme_log_err_event_process_inner_json : 583)acme_log_err_event_process_inner_json: type = urn:ietf:params:acme:error:rateLimited, detail = Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/

   (acme_post : 742)acme_post: return code 429, json=

   (cert_issue : 1303)failed to create new order at https://acme-v02.api.letsencrypt.org/acme/new-order

   (acme_error : 268)the server reported the following error:

   (acme_cert_valid_and_issue : 1669)/etc/acme/try.fwbtestgslb.com cert issue failed

   (cert_load : 1282)/etc/acme/try.fwbtestgslb.com/cert.pem does not exist

   (acme_update_cert : 1127)acme_update_cert:1127: update CMDB entry try.fwbtestgslb.com status to 7

5. Let's Encrypt only allows 5 times of certificate obtaining failure per hour for each host name and account. Please check if the number of retries reaches this limitation.

   If FortiWeb fails to obtain the certificate, it will try again every 2 hours until the certificate is successfully obtained.

   You can also manually obtain the certificate by clicking the Issue button. FortiWeb will obtain the certificate immediately.

   

   If the following error message displays, it means you have retrieved the certificate too frequently. You will see below information in the event log or diagnose output:

   Let's Encrypt failed to issue certificate due to error. type: urn:ietf:params:acme:error:rateLimited, detail: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/

How will LetsEncrypt certificate be renewed?

On 7.0.1 and previous builds, Letsencrypt certificates will be renewed automatically every 90 days. 5 days before your letsencrypt certificate expires, FortiWeb renews it for another 90 days, so it never expires.

From 7.0.2, FortiWeb supports setting Renew Period, that is the number of days to renew a certificate before it expires. The default value is 30 days.

Why can’t a browser connect securely to my back-end server?

If a browser cannot communicate with a back-end server using SSL or TLS, use the following troubleshooting steps to resolve the problem:

1. Without connecting via FortiWeb, ensure that you can access the server using HTTPS.

2. Ensure that your browser supports HTTP Strict Transport Security (HSTS). For example, following web page provides compatibility tables for various web browser versions:

http://caniuse.com/stricttransportsecurity

3. Ensure that the FortiWeb response includes the strict transport security header.

To add this header, select Add HSTS Header in the server policy or server pool configuration. For details, see "Configuring a server policy" or "Creating a server pool" in FortiWeb Administration Guide.

4. Use the following to ensure that the server certificate is trusted:

• If the certificate is signed by intermediate certificate authority (CA), the intermediate CA is signed by a root CA.

• The root CA is listed in your browser’s store of trusted certificates.

• The domain name or IP address is consistent with the certificate subject.

For details, see "Uploading a server certificate" in FortiWeb Administration Guide.

How to backup & restore private keys

• Refer to Admin Guide > How to set up your FortiWeb > Secure connections > How to export/backup certificates & private keys.

• Local certificates are stored at: /data/etc/cert/local/root

  /data/etc/cert/local/root# ls

  FortiWeb_CA.cer server_2048.cer server_4096.cer

  FortiWeb_CA.key server_2048.key server_4096.key

Keys are encrypted. During the encryption process, we will convert the key file into a matrix system and perform matrix conversion and hashing algorithms to protect each key file.