Section 1: Troubleshooting SCEP certificate enrollment. During the troubleshooting of SCEP certificate enrollment, several important points should be considered: The DNS section must be included in the configuration. Multiple DNS entries can be added within the same command, depending on the required configuration. Reachability of the CA server must be verified, and connectivity from FortiGate to the CA server must be confirmed. To verify network connectivity, the sniffer command can be used. A source IP address can also be specified in the command, if required. The command must be executed at the global level. After execution, certificate verification can be performed using the command 'show vpn certificate local'.
Command execution may not always complete successfully. Issues may be encountered during certificate regeneration. To troubleshoot these problems, sniffer and debug commands can be used to monitor what happens in real time and identify the root cause of the issue.
FortiGate (vdom) # diagnose sniffer packet any 'host <CA Server IP
Address> and port 443'6 0 l
Review SCEP debug logs to confirm certificate verification, PKCS processing, transaction creation, and server responses. SCEP Debug commands:
FortiGate (global) # diagnose debug application scep -1
FortiGate (global) # diagnose debug enable
Here, an example of SCEP debug logs is provided to offer further clarification: The following logs show multiple entries of __ssl_cert_verify_cb indicating successful certificate verification at different depths (2, 1, and 0). This means the certificates from the root, intermediate, and end-entity are verified successfully. It also shows that the certificates have been issued by Sectigo Limited, a well-known Certificate Authority (CA):
__ssl_cert_verify_cb: Certificate verification preverify_ok = 1,
depth = 2, subject = 'C = GB, O = Sectigo Limited, CN = Sectigo
Public Server Authentication Root R46'
__ssl_cert_verify_cb: Certificate verification preverify_ok = 1,
depth = 1, subject = 'C = GB, O = Sectigo Limited, CN = Sectigo
Public Server Authentication CA OV R36'
__ssl_cert_verify_cb: Certificate verification preverify_ok = 1,
depth =Â 0, subject = 'C = GB, ST = Manchester, O = Sectigo Limited,Â
CN = test.com'
A new SCEP transaction is initiated with the transaction ID xxxxxxxx:
new_scep_transaction: transaction id:Â xxxxxxxx
The logs show the creation of PKCS#7 envelopes, which are used to securely package the data. The payload is encrypted and base64 encoded successfully:
pkcs7_wrap:1124 creating inner PKCS#7
pkcs7_wrap: data payload size: 935 bytes
pkcs7_wrap: successfully encrypted payload
pkcs7_wrap: envelope size: 1384 bytes
pkcs7_wrap: creating outer PKCS#7
pkcs7_wrap: signature added successfully
pkcs7_wrap: adding signed attributes
__add_attribute_string: adding string attribute transId
__add_attribute_string: adding string attribute messageType
__add_attribute_octet: adding octet attribute senderNonce
pkcs7_wrap: PKCS#7 data written successfully
pkcs7_wrap:Â applying base64 encoding
pkcs7_wrap: base64 encoded payload size: 4319 bytes
A status code 200 is returned by the server, indicating that the request was received and processed:
scep_parse_header: server returned status code 200
scep_parse_header: MIME header: x-pki-message
pkcs7_unwrap: reading outer PKCS#7
pkcs7_unwrap: PKCS#7 payload size: 2583 bytes
pkcs7_unwrap: PKCS#7 contains 0 bytes of enveloped data
pkcs7_unwrap: verifying signature
pkcs7_unwrap: signature ok
pkcs7_unwrap: finding signed attributes
__get_attribute: finding attribute transId
__get_signed_attribute: allocating 32 bytes for attribute
The following log entry, pkcs7_unwrap: pkistatus: failure, indicates that the SCEP transaction failed:
pkcs7_unwrap: pkistatus:Â FAILURE
__get_attribute: finding attribute failInfo
__get_signed_attribute: allocating 1 bytes for attribute
pkcs7_unwrap: reason:Â transaction not permitted or supported
The failure reason is reported as transaction not permitted or supported, suggesting that the server does not allow the requested operation, or it is not supported by the server's configuration. To resolve the issue of the transaction not being permitted or supported, it is recommended that the following items be reviewed: Check server configuration: Ensure that the SCEP server is configured to support the requested transaction type. Verify permissions: Confirm that the client has the necessary permissions to perform the transaction. Review CA policies: Check if there are any CA policy restrictions that might be causing the transaction to be denied.
For example, one of the most common issues that can occur is that the challenge password is sent in a format that the CA server cannot decode. As a result, the server may return a message such as 'failed to decode challenge password attribute as string'. Another common scenario is that the password used is incorrect. Once the password is corrected, the SCEP transaction will complete successfully.
Section 2: Troubleshooting auto-renewal.
Usually, after the certificate is successfully generated, the auto-regenerate-days and auto-regenerate-days-warning values are configured. If during the configuration of those values, the following error occurs, it is likely because the command was configured in a specific VDOM, such as the root VDOM, instead of being executed in the global VDOM.
object set operator error, -14 discard the setting
Command fail. Return code -14
To resolve this issue, the command should be executed in the global VDOM. Additionally, to clarify the 'auto-regenerate-days' and 'auto-regenerate-days-warning' values for better understanding, an example is provided: If the certificate is generated on June 14th, And the auto-regenerate-days-warning is set to 9 days, And the auto-regenerate-days is set to 8 days, Given a certificate validity of 10 days, The warning log would be generated on June 15th, which is 9 days before expiry, And the auto-renewal would occur on June 16th, which is 8 days before expiry.
In summary, if:
Then:
To view the logs, the system event logs must be examined, and within these logs, the relevant keywords like 'msg=Certificate will be auto-regenerated' should be searched for messages indicating upcoming auto-regeneration and successful regeneration:
type="event" subtype="system" level="warning" vd="root"
logdesc="Certificate will be auto-regenerated" user="system"
action="certificate-regenerate" status="warning" cert="TEST"
msg="Local certificate TEST will auto-regenerate in 9 days."
type="event" subtype="system" level="warning" action=
"certificate-regenerate" msg="Local certificate TEST will
auto-regenerate in 8 days." logdesc="Certificate will be
auto-regenerated" user="system" status="warning"
cert="TEST"
Section 3: Validating regenerated certificates. After auto-regeneration has completed successfully, validating the regenerated certificate by using it in the intended deployment, such as SSL VPN pre-login, is a requirement.
For example, if the certificate is intended for use in pre-login (using SSL VPN), the relevant configuration on the FortiGate must be updated, and then the necessary tests must be performed to complete the validation. If the certificate is used for pre-login and does not function as expected, such as when the VPN connection cannot be established, the SSL VPN logs on the FortiGate and the FortiClient diagnostic logs on the endpoint should be reviewed.
FortiGate, in VDOM:
diagnose vpn ssl debug-filter src-addr4 <Source Public IP Address>
diagnose debug application sslvpn -1
diagnose debug console timestamp enable
diagnose debug enable
FortiClient Diagnostic Logs: Diagnostic_Result Folder -> FCDiagData -> General -> Logs -> Trace -> sslvpnlib (for Windows FortiClient).
The VPN gateway certificate is validated by FortiClient. One common issue in this case is that an error such as 'no certificate received' may appear in the SSL VPN logs in FortiGate, and in the FortiClient diagnostic logs, the certificate might be flagged as failed.
From the FortiGate logs:
sslvpn_update_user_group_list:xxxx got user (0:0), group (0:0), peer group (1)
after update.
sslvpn_authenticate_cert_start:xxx No client certificate received.
get_cust_page:xxx saml_info 0
From the FortiClient logs:
[sslvpnlib 707 debug] 1,WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED
[sslvpnlib 615 debug] dwInternetStatus:2097152.
[sslvpnlib 686 debug] dwInternetStatus:
WINHTTP_CALLBACK_STATUS_REQUEST_ERROR.
[sslvpnlib 688 debug] dwResult:5, dwError:12175
[sslvpnlib 6660 debug] CSslvpnBase::
ShowServerCerttificateWarningMessage() called
[sslvpnlib 6666 warning] CSslvpnBase::
ShowServerCerttificateWarningMessage() Strict server certificate
rule applied.
[sslvpnlib 615 debug] dwInternetStatus:2048.
[sslvpnlib 645 debug] dwInternetStatus:
WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING.
[sslvpnlib 2057 error] Empty web page, return FALSE.
This issue may be caused by a failure in a Windows API call, where the system attempts to call the Certificate Revocation List and fails. This may be because the Certificate Revocation List URL is only accessible internally, which is a common practice for private certificate structures, and machines running FortiClient may not be able to access this list yet, as they have not connected to the internal network via the SSL VPN. As a result, the configured Certificate Revocation List URL cannot be reached over the public internet, which means private certificates cannot be used as expected.
Related document: WINHTTP_STATUS_CALLBACK (winhttp.h) To address this, depending on the organization’s policies, either private certificates can be created without defining a Certificate Revocation List, or a publicly available Certificate Revocation List for private certificates can be used. | 
