FortiADC SSL Offloading in Dubai, UAE
When HTTPS traffic becomes a significant part of application load, the encryption work itself can become a design concern. FortiADC SSL offloading places FortiADC between clients and backend services so the ADC can terminate client-side TLS, apply delivery or security policies, and forward traffic according to the architecture chosen by the application team. The result is not simply “faster SSL”; it is a controlled point for certificates, encrypted-session handling, load balancing, visibility and server-resource planning.
Start with the traffic, not the model
For a useful FortiADC quote, share your peak HTTPS throughput, estimated TLS transactions, number of applications, certificate count, desired re-encryption policy and high-availability requirement.
Direct answer: what does FortiADC SSL offloading do?
FortiADC SSL offloading lets a FortiADC virtual server handle the SSL/TLS handshake and encrypted client connection on behalf of backend application servers. Fortinet documents this as a Layer-7 load-balancing use case in which FortiADC uses the relevant server certificate and private key, decrypts incoming HTTPS traffic and then forwards requests according to the configured design. The backend side may remain unencrypted or may use a separate real-server SSL profile for re-encryption. Organisations should consider it when HTTPS processing, certificate control, application visibility or load-balancer security functions need to be centralised. Before proceeding, confirm certificate ownership, TLS policy, expected encrypted traffic volume, backend trust requirements, model capacity, HA design and whether security subscriptions are required.
What the solution does
The core idea is to move the expensive and operationally sensitive parts of TLS termination from each application server to an application-delivery tier. A client opens an HTTPS session to a FortiADC virtual server. FortiADC presents the configured certificate, negotiates the TLS connection, decrypts the request and then applies the load-balancing, routing, security or visibility functions that have been enabled. The request is subsequently delivered to an appropriate real server. Depending on policy, the server-side leg can use clear HTTP on a protected segment or a new TLS session between FortiADC and the backend.
That design changes where certificate keys, cipher policies and encryption workload are managed. It can simplify administration when many servers publish the same service, but it also creates a responsibility to protect private keys, keep certificate chains correct, maintain compatible TLS settings and size the ADC for peak encrypted demand.
Who should consider it
FortiADC SSL offloading is relevant to organisations that run business-critical HTTPS services behind more than one server, regularly manage certificates across a server farm, expect large volumes of encrypted sessions, or want security controls to see traffic after decryption. Typical environments include e-commerce sites, customer portals, banking and financial applications, healthcare portals, enterprise ERP front ends, API services, SaaS platforms and data-centre applications.
It is not automatically the right choice for every website. A small application with modest traffic may not justify a dedicated ADC. Applications that rely on strict end-to-end TLS semantics, certificate pinning, mutual TLS, application-layer source assumptions or unusual session behaviour require careful testing. The correct decision comes from application behaviour and operational requirements, not from a general assumption that every HTTPS workload needs offload.
Business problems this architecture can address
Backend CPU pressure
Encrypting and decrypting large volumes of HTTPS can consume server resources. Moving TLS processing to FortiADC can allow application servers to focus more of their compute capacity on application logic, database requests and content generation.
Certificate sprawl
When the same public service is distributed across many servers, certificate replacement and cipher-policy consistency can become difficult. Central termination can reduce the number of endpoints that need to expose the public certificate and key, although backend trust still needs to be designed carefully.
Encrypted traffic visibility
Security services cannot inspect application payloads that remain encrypted. FortiADC can decrypt traffic at the delivery tier and, depending on configuration and subscribed functions, apply inspection or provide decrypted visibility to other controls.
Scaling HTTPS services
As user demand grows, an ADC can combine TLS termination with L4-L7 load balancing, health checks and routing. This makes encryption capacity one part of a larger application-scaling design instead of leaving each server to manage sessions independently.
FortiADC SSL offloading capability band
TLS termination
FortiADC can terminate the client-side secure session on a virtual server using configured certificates and TLS settings.
Server-side re-encryption
Real-server SSL profiles can be used where the backend leg must also remain encrypted rather than sending clear traffic.
TLS 1.3 support
Fortinet’s current FortiADC data sheet lists TLS 1.3 under advanced SSL services, alongside offloading, mirroring and forward proxy functions.
Certificate management
Client-side and server-side SSL management are part of the current platform feature set, including certificate-chain and local-certificate handling.
Which type of requirement is a good fit?
| Requirement | Suitable when | Confirm before ordering |
|---|---|---|
| High-volume HTTPS | Encrypted traffic is material enough to affect server or ADC sizing. | Peak TLS bulk throughput, handshake rate, cipher mix and session reuse. |
| Central certificate handling | Many real servers publish one or more shared public services. | Certificate format, private-key custody, CA chain and renewal process. |
| Security inspection | Security functions need access to application payload after decryption. | Required FortiADC bundle, privacy impact, inspection scope and downstream tools. |
| End-to-end encryption | Clients terminate at FortiADC but backend traffic must remain TLS-protected. | Real-server SSL profile, backend certificates, trust chain, mTLS behaviour and ciphers. |
| HA application delivery | The service needs redundant ADC design as well as backend redundancy. | HA mode, network paths, certificate synchronisation, session behaviour and failure testing. |
Verified FortiADC information relevant to SSL offloading
The figures below are model-specific examples from Fortinet’s current FortiADC data sheet. They are not a combined specification and should not be treated as a substitute for model sizing.
| Platform type | FortiADC is available as hardware appliances, virtual machines and public-cloud deployments. Current Fortinet material also references FortiFlex deployment options. |
| Advanced SSL services | TLS 1.3, SSL offloading, SSL mirroring, SSL forward proxy and client/server-side SSL management are listed in the current FortiADC feature set. |
| FortiADC 220F | Software SSL acceleration; 1.2 Gbps TLS bulk encryption throughput in Fortinet’s published test profile. The exact result in production depends on traffic, cipher use, configuration and other services. |
| FortiADC 320F | Software SSL acceleration; 6 Gbps TLS bulk encryption throughput in the current data sheet test profile. |
| FortiADC 420F | ASIC SSL acceleration; 20 Gbps TLS bulk encryption throughput in the current data sheet test profile. |
| Higher-capacity G-series examples | Fortinet’s current data sheet shows ASIC SSL acceleration on FAD-1000G, FAD-2000G, FAD-4000G and FAD-5000G, with much higher published TLS bulk throughput. Select the exact model only after sizing. |
| Certificates | Fortinet documentation requires the appropriate X.509 server certificate and private key for client-side SSL termination, plus CA/intermediate certificates needed to complete the chain of trust. |
| Backend TLS | Real-server SSL profiles control the FortiADC-to-server encrypted leg when re-encryption is required. |
| Security-service dependency | Some application and network security functions depend on the selected FortiADC bundle or subscription. Confirm the required services before quotation. |
Important dependency: offloading is not the same as disabling encryption
A common planning mistake is to treat SSL offloading as a simple choice between HTTPS and HTTP. In reality, there are at least two separate TLS relationships to consider: the client-to-FortiADC connection and the FortiADC-to-real-server connection. Some applications are comfortable with a decrypted backend segment inside a tightly controlled network zone. Others require TLS all the way to the server because of internal security policy, compliance expectations, multi-tenant infrastructure, cloud network design or application behaviour. FortiADC can be designed for re-encryption, but that introduces additional certificate, trust, cipher, performance and troubleshooting requirements. Mutual TLS adds further considerations because client-certificate identity may need to be preserved or delegated. Document the intended trust boundary before selecting a model or building policies.
A practical SSL offloading deployment journey
Profile the application
List every public or private application to be published, its current VIP, server pool, ports, HTTPS behaviour, authentication method and business criticality. Capture peak periods rather than daily averages.
Measure TLS demand
Estimate encrypted throughput, connection rate, handshake characteristics, certificate type, cipher requirements and whether HTTP/2 or other application behaviours matter. This is the basis for ADC sizing.
Choose the trust boundary
Decide whether traffic from FortiADC to real servers can be clear text in a protected segment or must be re-encrypted. Include mTLS, internal CA and backend certificate validation requirements.
Select model and bundle
Compare hardware, VM or cloud deployment, TLS headroom, network interfaces, security services, support term, resilience requirements and future application growth.
Build and test
Import certificates securely, configure client and server SSL profiles, create the virtual server and health checks, then test redirects, cookies, authentication, headers, client IP handling and failure behaviour.
TLS capacity should be sized independently from general throughput
A FortiADC model can have strong Layer-4 or Layer-7 throughput yet still have a different ceiling for encrypted processing. Buyers therefore need to look at the SSL/TLS performance metrics that are relevant to the actual workload. Bulk TLS throughput matters when users transfer substantial encrypted content. TLS transactions per second matter when the service creates many new secure sessions. Session reuse, keep-alive behaviour and cipher selection can change the practical load. ECDHE and ECDSA or RSA choices also affect handshake cost differently.
Fortinet’s current data sheet demonstrates why model-by-model validation matters. The 220F and 320F use software SSL acceleration in the published specification, while the 420F uses ASIC acceleration. Higher-capacity G-series models use ASIC acceleration and publish progressively larger TLS capacities. Those figures are useful as comparison points, but production sizing needs headroom for traffic growth and any additional services that run on the same appliance.
FourTeck can help turn observed or estimated application traffic into a sizing discussion. If monitoring data is available from the existing load balancer, web tier, firewall, CDN or application performance system, include it. If no historical data exists, provide peak concurrent users, transaction patterns, average response sizes, number of public hostnames and any expected business growth. The goal is not to pick the model with the largest number; it is to avoid a design in which encrypted traffic becomes the unplanned bottleneck.
Certificate and private-key operations become part of ADC operations
Once FortiADC terminates TLS, certificate lifecycle management becomes an application-delivery responsibility. The team needs a defined process for certificate requests, validation, import, renewal, private-key protection, intermediate CA chains and expiry monitoring. A failed or incomplete certificate chain can create client trust errors even when the application servers themselves are healthy. A certificate that does not include the required hostname in its subject alternative names can also break access immediately.
The same discipline applies to server-side re-encryption. If FortiADC establishes TLS to real servers, the backend trust model must be documented. Decide whether real-server certificates come from an enterprise CA, a public CA or another trusted source. Confirm whether FortiADC should validate them and how name matching will work. Mutual TLS may require additional client-certificate handling and should be tested with the application owner rather than assumed from a basic HTTPS test.
For procurement, certificate planning may not change the FortiADC SKU directly, but it changes implementation scope and risk. A quotation that includes only hardware or a VM license is different from one that includes certificate migration, SSL profile design, policy conversion and controlled cutover assistance. Share the current certificate inventory and renewal method with FourTeck if these services are expected as part of the project.
SSL offloading can support inspection, but security services remain separate decisions
Decryption creates visibility, but it does not automatically mean that every security function is enabled. FortiADC can combine application delivery with functions such as WAF, IPS, antivirus, IP reputation, credential-stuffing defence, sandbox integration, DLP and advanced bot protection depending on the selected feature set and subscription bundle. The appropriate security layer depends on application exposure, data sensitivity, existing FortiGate or FortiWeb controls, and the operations team’s ability to tune policies.
Some organisations use FortiADC mainly as an application-delivery and SSL-processing platform. Others expect it to enforce application protection at the same point where encrypted traffic is terminated. A third design may use SSL visibility or mirroring to give another inspection device access to decrypted traffic. Each approach affects traffic flow, capacity, policy ownership and incident troubleshooting.
For this reason, do not buy a security bundle only because “SSL inspection” sounds desirable. Identify which control is actually required, which team will manage it and where equivalent inspection may already exist. FourTeck can help map those requirements to the FortiADC options being quoted, while final feature availability should be confirmed against the selected software version, model and subscription.
Where FortiADC SSL offloading can fit in real environments
E-commerce and customer portals
HTTPS is mandatory for sign-in, account activity, checkout and personal data. Offloading can combine encrypted-session handling with server load balancing and application-delivery policy. Buyers should pay close attention to peak campaign traffic, payment redirections, sticky sessions, API endpoints and certificate renewal windows.
Enterprise application publishing
ERP, CRM, HR and collaboration services may run across several application servers or data-centre zones. FortiADC can terminate user TLS at the application-delivery tier and distribute requests to healthy backends, but authentication, SSO, headers and client-address requirements must be validated.
API and mobile backends
API workloads can generate many short-lived encrypted connections and may use strict authentication or mTLS. Sizing therefore needs more than bandwidth. Confirm handshake rate, keep-alive behaviour, certificate validation and how the ADC will preserve or rewrite application headers.
Data-centre consolidation
When organisations replace multiple legacy load balancers, central TLS handling can simplify certificate operations and create a consistent policy point. Migration planning should inventory every virtual server and unusual profile before the old platform is removed.
Hybrid cloud delivery
FortiADC is available in hardware, VM and public-cloud forms. A hybrid design may keep some applications on-premises while placing others in cloud infrastructure. TLS policy, certificates, DNS and global traffic steering need to be coordinated across those locations.
Security visibility projects
Organisations may terminate or mirror encrypted traffic so security tools can examine content that would otherwise remain opaque. Privacy, legal scope, data handling and performance impact should be reviewed before enabling inspection broadly.
Integration and operational considerations
SSL offloading sits in the middle of the application path, so it interacts with more systems than a certificate alone. DNS must point users to the correct virtual IP. Firewalls must permit the required client and server flows. Health checks need to represent real application health rather than simply testing whether a TCP port opens. If the backend sees the FortiADC address instead of the original user address, the application or logging platform may need a client-IP preservation method or a trusted HTTP header. If authentication depends on the source IP, TLS client certificate, SNI hostname or particular HTTP header, the behaviour must be tested explicitly.
Monitoring should also be planned. Application teams usually need to distinguish between a failed TLS handshake, an ADC policy issue, an unhealthy real server and an upstream network fault. FortiADC provides logging, monitoring and FortiView capabilities, and the current platform supports integration with FortiAnalyzer, FortiSIEM and other systems. Decide which team owns daily monitoring and where alerts should be sent. A successful deployment is one that operations staff can support after the project team leaves, not merely one that passes an initial browser test.
High availability deserves its own test plan. A pair of ADCs may protect the delivery tier, but failover still depends on surrounding routing, switching, VLANs, upstream firewalls and server networks. Verify certificate and configuration synchronisation, expected session impact during failover and whether application owners can tolerate session re-establishment. For critical services, schedule controlled failover testing rather than waiting for a real outage to reveal assumptions.
Questions buyers should resolve before requesting a FortiADC quote
How much encrypted traffic is really present?
Use peak data when possible. Include both sustained HTTPS throughput and the rate of new TLS sessions. A workload with many short API calls can create a different sizing problem from one that transfers large files through long-lived connections.
Will traffic be re-encrypted to the servers?
This determines whether the ADC performs one or two TLS operations in the application path and affects backend certificates, trust policies, troubleshooting and capacity planning.
Which certificates and keys must be migrated?
Provide the number of hostnames, certificate type, issuing CA, expiry dates, private-key format, any HSM requirement and whether wildcard or SAN certificates are used.
Which security services are expected?
Separate SSL termination from WAF, IPS, antivirus, bot protection, sandboxing and DLP requirements. These can change the subscription bundle and appliance load.
Is hardware, VM or cloud preferred?
Deployment format influences interface needs, compute allocation, licensing, cloud architecture and how capacity is expanded. Match the ADC to where the applications actually run.
What must happen during failure?
Define acceptable interruption, HA topology, upstream redundancy, DNS behaviour and maintenance expectations. Availability is an architecture outcome rather than one appliance feature.
Procurement checklist for FortiADC SSL offloading
☐ Exact deployment format: hardware appliance, virtual appliance or public-cloud option
☐ Peak HTTPS throughput and expected TLS transactions per second
☐ Number of public applications, hostnames and virtual servers
☐ Certificate inventory, CA chain, key format and renewal responsibility
☐ Client-side TLS versions, cipher policy and any mTLS requirement
☐ Backend encryption or re-encryption requirement
☐ Required network interfaces, VLANs and data-centre connectivity
☐ High-availability design and failure-test expectations
☐ WAF, IPS, AV, reputation, bot, sandbox or DLP service requirements
☐ Desired support and subscription term
☐ Installation, migration, cutover and rollback scope
☐ UAE delivery destination and desired project timeline
Quotation tip: attach a simple application-flow diagram and existing load-balancer configuration summary if available. That often answers more sizing questions than a generic request for “one FortiADC for SSL offload.”
How FourTeck can assist with planning and quotation
Requirement review
FourTeck can help structure the conversation around applications, peak encrypted traffic, server pools, certificates, availability expectations and deployment location before a model is shortlisted.
Model and license guidance
The FortiADC family spans different performance levels and deployment forms. We can help compare suitable options and identify where security subscriptions or support terms may affect the bill of materials.
Configuration scope
If implementation assistance is required, define whether it includes certificate import, SSL profiles, virtual servers, real-server pools, health checks, HA, testing, migration and documentation.
Commercial coordination
Availability and pricing depend on exact model, bundle, support term, quantity and vendor lead time. FourTeck can prepare a quotation after the technical requirement is sufficiently defined.
For related infrastructure planning, buyers can review FourTeck technology products, discuss implementation through FourTeck services, or explore broader Fortinet solution guidance. These links are useful when the SSL offloading project also touches firewalls, security inspection, switching or application migration.
UAE availability and support guidance
Contact FourTeck to confirm current UAE availability for the FortiADC model, VM entitlement, cloud option, FortiCare support term and any required FortiADC security subscriptions. Availability may depend on the model, bundle, quantity, license region, supplier status and vendor lead time. Because SSL offloading capacity varies considerably across the product family, FourTeck recommends completing a technical sizing review before treating any quotation as final.
Delivery and project coordination can be discussed after the exact requirement is confirmed. If the order includes installation or configuration, include that scope in the quotation so responsibilities for certificate handling, virtual server creation, re-encryption, health checks, HA and cutover testing are clear. Businesses can use the FourTeck contact page to share their application and procurement details.
Dubai, Abu Dhabi, Sharjah and Ajman coverage
Organisations in Dubai, Abu Dhabi, Sharjah and Ajman can request FortiADC product guidance, quotation coordination, availability checks and implementation-scope discussions. The practical starting point is the same across the UAE: provide the application list, peak HTTPS load, certificate requirements, preferred deployment type, support term and destination. FourTeck can then help narrow the FortiADC options without assuming that one appliance size or license bundle fits every project.
GCC Availability
FourTeck can assist organisations planning FortiADC SSL offloading projects across GCC markets with requirement review, model and license selection, quotation coordination, delivery planning and configuration-scope discussions. A regional project may involve applications hosted in the United Arab Emirates with users or secondary sites in Saudi Arabia, Kuwait, Qatar, Bahrain or Oman, or it may require separate ADC deployments in more than one country. In either case, capacity, licensing, support and logistics should be validated for each destination rather than copied from one site to another. Product availability, service visits, project scope and vendor lead times can vary by country, model, quantity and commercial requirement. Buyers should share the destination country, exact FortiADC requirement, quantity, requested license or support term, deployment location and expected timeline. Where Kuwait is part of the project, the FourTeck Kuwait platform can also support regional inquiry coordination. Final delivery and implementation commitments should be confirmed in the accepted quotation.
Africa Availability
African organisations evaluating FortiADC SSL offloading can approach the requirement as a combined application-delivery, certificate and procurement project. FourTeck can help teams review suitable FortiADC deployment forms, licenses, support terms, network interfaces, certificate dependencies and implementation expectations before a commercial request is finalised. Requirements often differ between a data-centre deployment, a cloud-hosted application and a regional service with users in several markets, so the destination and hosting architecture matter. Availability and fulfilment may depend on the destination country, selected model, quantity, license region, power and regulatory conditions, shipping method, vendor lead time and whether local implementation assistance is required. Buyers should provide the destination, exact requirement, quantity, preferred deployment schedule and support expectations. For relevant regional inquiries, FourTeck maintains Africa technology channels as well as dedicated Kenya and Uganda platforms. Current stock, shipment timing and onsite scope should always be confirmed for the specific project rather than assumed.
Related options and adjacent services to consider
FortiADC hardware sizing
Compare current hardware models by TLS capacity, L4/L7 performance, interfaces, resilience and future headroom rather than selecting by a single headline number.
FortiADC VM or cloud deployment
Useful when applications are virtualised or cloud-hosted. Confirm platform support, vCPU entitlement, cloud marketplace model, network architecture and performance limits.
Application security bundle review
Consider WAF, credential-stuffing defence, sandboxing, DLP or bot protection only when those controls are required by the application risk profile and operations plan.
FortiGate integration planning
Encrypted-traffic visibility and application delivery may interact with FortiGate placement. Review whether inspection happens on FortiADC, FortiGate or both and avoid duplicated processing without a clear purpose.
Migration and cutover assistance
Legacy ADC replacements need configuration inventory, certificate transfer, virtual server recreation, application testing, rollback planning and a controlled change window.
What buyers are really trying to solve with SSL offloading
Many buyers begin with a narrow question: “Can FortiADC take SSL load away from my servers?” The answer is yes, but the useful decision comes from understanding what kind of SSL load exists and what the organisation wants to gain by moving it. Search and procurement discussions commonly revolve around five themes: performance, certificate management, load balancing, security inspection and model sizing. Treating these as one problem often leads to better architecture than buying an ADC only because web-server CPU happens to be high.
“Will offloading make my website faster?”
It can reduce cryptographic work on the backend and can place SSL processing on hardware or software designed for application delivery, but overall response time still depends on application code, databases, network latency, caching, server health and the ADC configuration. Measure the current bottleneck before assuming TLS is the dominant issue.
“Do I still need HTTPS to the backend?”
That is a security-architecture decision. Offload can mean TLS ends at FortiADC, but FortiADC can also establish a new encrypted connection to the real server. Re-encryption is common where internal policy requires encryption in transit, where traffic crosses shared infrastructure, or where application owners do not want a clear backend leg.
“Which FortiADC model is enough?”
Start with encrypted traffic and handshake demand, then add capacity for L7 processing, security services, growth and HA. Fortinet’s current product family spans software-accelerated and ASIC-accelerated models with very different published TLS figures. A general internet-speed number is not enough for sizing.
“Can FortiADC manage several certificates?”
Yes, certificate and SSL profile management are central parts of the platform, but the operational question is who owns renewals, private keys and certificate changes. A central ADC can reduce repetition, yet it also becomes a sensitive certificate-management point that needs controlled access and a documented renewal process.
Another recurring buyer concern is the difference between SSL offloading and SSL inspection. Offloading describes where TLS is terminated and processed for application delivery. Inspection describes what security controls do with the decrypted content. FortiADC can support both concepts, but enabling one does not automatically enable every security service. If the project requires WAF, IPS, antivirus, reputation services or advanced application protection, those requirements should appear explicitly in the bill of materials and operational plan.
Buyers also ask whether a virtual FortiADC can perform SSL offloading. Fortinet offers FortiADC as virtual appliances and through public-cloud deployment options, so the answer can be yes. The important distinction is how performance is licensed and resourced compared with a physical appliance. Hardware models can include dedicated acceleration on selected platforms, while VM performance depends on the virtual entitlement and underlying compute resources. Cloud deployments add another layer of design around public addresses, subnets, routing, cloud load balancers and marketplace licensing.
Migration questions are equally important. Replacing an existing F5, Citrix ADC, HAProxy, NGINX or another application-delivery platform is not simply a matter of copying certificates. Existing virtual servers may depend on persistence methods, health checks, header insertion, redirects, content rules, source-NAT behaviour or custom scripts. Those details can materially affect user sessions after cutover. An application-by-application migration inventory is usually safer than a “lift everything at once” approach.
When preparing a quotation request, provide enough information for both technical and commercial sizing: application count, peak HTTPS throughput, expected new connections or TLS handshakes, certificate count, re-encryption requirement, network interfaces, HA expectation, required security services, preferred support term and deployment site. That information allows FourTeck to compare suitable FortiADC choices without pretending that a generic SSL offloading SKU has one universal performance or price.
Decision questions that clarify the right design
Should we size by Mbps/Gbps or by TLS transactions?
Use both where possible. Bulk encryption throughput shows how much encrypted data the ADC can process, while TLS transactions per second help describe handshake-heavy workloads. A large file portal and a mobile API can show similar bandwidth but very different connection patterns. Include concurrency and session reuse if you can measure them.
What happens to client identity after TLS termination?
It depends on application design. The backend may see FortiADC as the network peer unless the architecture preserves the source address or passes trusted client information through an application header. If security decisions, logging or rate limits depend on the original address, define that requirement before cutover and ensure the backend trusts only controlled sources.
Can we use one certificate for several applications?
Potentially, but certificate design comes first. A wildcard or multi-domain certificate may cover several hostnames, while other organisations intentionally separate certificates by application or security zone. The certificate must match the client hostname, be within its validity period and include the correct trust chain. Private-key governance should influence the choice as well.
Do we need a dedicated security bundle just for SSL offload?
Not necessarily. SSL offloading is an application-delivery capability, while advanced security services may be bundle or subscription dependent. Define whether the project needs WAF, IPS, malware inspection, reputation controls, bot protection or other services, then map those requirements to the current FortiADC licensing options.
How much capacity headroom should we leave?
Leave room for real peaks and future changes. Exact headroom depends on business growth, application criticality, security services and the organisation’s change cycle. A platform operating comfortably during normal traffic can still become constrained during campaigns, month-end processing or failover if the surviving unit must carry the full load.
What information makes a quote more accurate?
Send a small technical profile rather than only a product name. Peak traffic, TLS session data, applications, certificates, backend count, network ports, HA, security subscriptions, support term, deployment site and implementation scope make it easier to identify an appropriate FortiADC option and avoid repeated commercial revisions.
Why businesses contact FourTeck for FortiADC projects
Application-delivery purchases often sit between networking, security and application teams. That can make even a straightforward request difficult because each group describes the requirement differently. Networking may focus on interfaces and routing. Security may focus on certificates, ciphers, inspection and access policy. The application team may focus on sessions, headers and downtime. Procurement still needs a clear SKU, term, price and delivery plan. FourTeck’s role in the discussion is to help convert those inputs into a procurement-ready requirement.
That may involve clarifying which FortiADC model range deserves evaluation, whether hardware or VM fits the hosting environment, what support or subscription term is required, and whether migration or configuration assistance needs to be quoted separately. It can also involve checking related dependencies such as FortiGate placement, switch ports, transceivers, cloud networking or certificate preparation. These are practical planning tasks rather than guarantees of compatibility or outcome.
For broader company information, visit About FourTeck. For a project-specific discussion, use Contact FourTeck Sales and include as much application and traffic information as possible.
Frequently asked questions about FortiADC SSL offloading
What is FortiADC SSL offloading used for?
It is used to terminate and process client SSL/TLS sessions on FortiADC instead of placing all encryption and decryption work on backend application servers. It can be combined with load balancing, certificate management and configured security or visibility functions.
Does SSL offloading mean backend traffic must be unencrypted?
No. FortiADC can terminate the client connection and then use a real-server SSL profile to establish a separate encrypted connection to the backend when end-to-end encryption is required by policy or architecture.
Which FortiADC model should I choose for SSL offloading?
Choose by measured or estimated TLS throughput, handshake rate, application traffic, required network interfaces, security services, HA design and future growth. Current FortiADC models publish different TLS performance figures, so one generic model recommendation would be inappropriate.
What certificates are required?
FortiADC needs the appropriate server certificate and private key for the client-facing service, along with CA or intermediate certificates needed to form the trust chain. Backend re-encryption may require additional real-server trust and certificate configuration.
Can FortiADC SSL offloading work with mutual TLS?
FortiADC supports client-certificate-related controls and server-side SSL profiles, but mTLS behaviour is design dependent. The required client identity, certificate validation and backend enforcement should be tested against the exact application workflow.
Is SSL inspection included automatically with offloading?
No. Offloading provides decrypted visibility at the ADC layer, but security functions such as WAF, IPS, antivirus, bot protection or other services depend on configuration and, in some cases, the selected FortiADC bundle or subscription.
Can FourTeck help migrate SSL services from an existing load balancer?
FourTeck can discuss migration and configuration scope. A useful migration plan should inventory certificates, virtual servers, pools, health checks, persistence, headers, redirects, NAT behaviour and rollback requirements before implementation is quoted.
How do I get UAE pricing and availability?
Share the preferred deployment type, performance requirement, quantity, support term, security services, delivery location and implementation scope with FourTeck. Current pricing and availability must be confirmed for the selected model, bundle and project timeline.
Plan the SSL offloading requirement before choosing the SKU
Send FourTeck your application count, peak HTTPS load, certificate details, backend encryption policy, security-service needs and preferred deployment format. We can help turn those inputs into a FortiADC sizing and quotation discussion for Dubai and the UAE.