FortiWeb Lesson 05: HTTPS Certificates, TLS and Trusted Client IPs
FORTIWEB CLASSROOM • LESSON 05
Level: Beginner to intermediate · Study and lab: 60 minutes
Instructor: Harpreet Singh Virdi, CISSP, CCSP
FortiWeb course guide · FortiWeb training block
Secure both sides of the proxy
In reverse proxy, the browser and origin usually participate in separate connections. A trusted browser-to-FortiWeb connection does not automatically secure the FortiWeb-to-origin connection. Draw both legs before configuring certificates.
Certificate fundamentals
A certificate binds an identity to a public key within a trust framework. The hostname, validity period, chain, private key, and supported TLS settings matter. The private key is sensitive. Do not publish it in screenshots, backups placed in public repositories, or help requests.
For the client-facing leg, use a lab certificate whose name matches books.example.test and whose issuer is trusted by the lab client. For origin HTTPS, configure the supported encryption and server-validation settings to match the origin's identity and trust requirements. Do not disable certificate checks to disguise a design error.
Guided TLS lab
- Record the hostname and trust expectations for each leg.
- Import the appropriate lab certificate and private key using the supported certificate workflow.
- Reference the certificate, or SNI configuration where needed, in the lab server policy.
- Configure origin HTTPS separately if the design requires it.
- Visit the virtual hostname and inspect the client-visible certificate.
- Send a normal application request and confirm inspection still occurs.
- In the isolated lab, deliberately use a mismatched test hostname and explain the resulting error; restore the valid configuration afterward.
Expected result: the intended hostname works with valid trust, and you can identify which connection fails when you introduce a mismatch.
Who is the client?
A load balancer or CDN in front of FortiWeb may become its immediate network peer. Forwarded headers can carry the original client address, but clients can also forge headers. Configure the proxy trust relationship so only the approved upstream path supplies authoritative client information.
This distinction affects logging, rate limits, source-based access rules, and bot decisions. Two people behind NAT may share one source address. One untrusted header value must not be treated as proof of user identity.
Client-IP exercise
- Send a request directly within the lab and record the observed source.
- If an approved test proxy is available, repeat through it and compare the immediate peer with the intended real client.
- Send an untrusted forwarded-header value from the direct client. Confirm it is not accepted as authoritative.
Knowledge check
Why might a rate-limit rule affect many innocent users behind a proxy?
Instructor answer
The rule may identify the proxy or shared NAT address as one client. Review the trust configuration and supported tracking scope before choosing thresholds.
Official reading
- Fortinet: how operation mode affects server policy behavior
- Fortinet: server policy policy
- Fortinet: 31455
Independent training, not affiliated with Fortinet. Examples use an authorized isolated lab with synthetic data. The lab steps and expected outcomes have not been executed on a FortiWeb appliance for this publication. Firmware, platform, operating mode, licensing, and subscriptions affect behavior; follow the documentation for your exact build. References use 8.0.x examples and do not constitute an upgrade recommendation.
← Previous FortiWeb lesson · FortiWeb course guide · Next FortiWeb lesson →
Comments
Post a Comment