NSE4 Security Profiles Practice Question
Exhibit
Refer to the exhibit.
```
config firewall ssl-ssh-profile
edit "deep-inspection"
set caname "Fortinet_CA_SSL"
config https
set ports 443
set status deep-inspection
end
set untrusted-caname ""
set whitelist-mode disable
next
end
```Refer to the exhibit. An administrator has configured the SSL/SSH profile shown. However, users are unable to access HTTPS websites. What is the most likely cause?
⚠ Common exam trap
It's easy for candidates to confuse the 'caname' and 'untrusted-caname' fields, assuming any CA name is sufficient, without understanding that the CA must be trusted by the client for the re-signed certificate to be accepted.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The 'untrusted-caname' should be set to a trusted CA certificate to handle untrusted server certificates.
When the SSL/SSH profile has 'untrusted-caname' set to 'Fortinet_CA_SSL' (an untrusted CA), the FortiGate cannot re-sign certificates from untrusted servers with a trusted CA. This causes HTTPS websites to fail as the client receives an untrusted certificate warning or connection error. Setting 'untrusted-caname' to a trusted CA certificate ensures that even untrusted server certificates are re-signed with a certificate the client trusts.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The 'untrusted-caname' should be set to a trusted CA certificate to handle untrusted server certificates.
Why this is correct
In FortiGate SSL inspection profiles, the 'untrusted-caname' parameter specifies a CA certificate used to re-sign server certificates that are not already trusted by the FortiGate, such as self-signed or internally issued certificates. If this field is left blank or points to an untrusted CA, the FortiGate will fall back to a default CA that clients do not recognize, causing certificate validation warnings and potential connection failures in web browsers. To ensure seamless inspection of sites with untrusted server certificates, the administrator must assign a trusted CA—typically the FortiGate's built-in CA or a corporate CA—so clients accept the re-signed certificates without alerts.
- ✗
The port is set to 443, but HTTPS also uses port 8443.
Why it's wrong here
While HTTPS commonly runs on ports other than 443, such as 8443 in application-specific deployments, the SSL inspection profile's port setting only defines which destination ports are intercepted for TLS inspection. Port 443 is the default and most widely used HTTPS port, and its presence in the profile is correct; the absence of an alternate port does not break inspection or indicate a misconfiguration. The profile can be extended to include additional ports if the environment requires it, but omitting a nonstandard port is not an error and is unrelated to the core issue of untrusted certificate handling.
- ✗
The 'caname' is set to 'Fortinet_CA_SSL', which is not a valid certificate name.
Why it's wrong here
'Fortinet_CA_SSL' is the default, valid name of the FortiGate's built-in certificate authority that is automatically generated during initial setup. In the 'caname' field, this reference is legitimate and correctly identifies the CA used to sign certificates for trusted server connections. It is not a typographical error or an invalid certificate name; rather, the problem lies in the separate 'untrusted-caname' field, which governs untrusted server certificates and is the actual root cause of the client-side warnings.
- ✗
The 'whitelist-mode' is disabled, which prevents inspection.
Why it's wrong here
The 'whitelist-mode' feature in FortiGate SSL inspection profiles is designed to exclude a predefined set of trusted, high-security websites from deep inspection, typically to avoid breaking sensitive services like banking or healthcare portals. Disabling this mode simply means the FortiGate will inspect all HTTPS sessions without those exemptions, which is a common and intended configuration for full visibility and does not prevent inspection at all. In fact, enabling whitelist mode would cause the FortiGate to skip inspection for whitelisted domains, so a disabled whitelist mode is not a fault and is irrelevant to the certificate-trust issue described.
Go deeper
Related to this question
About these practice questions
Courseiva writes every NSE4 question from scratch — 773 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE4 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE4 exam.