Before you buy anything, it’s worth spending five minutes working out what you actually need. The short version: most SAP landscapes need fewer certificates than people expect, because a single SAP Web Dispatcher (or reverse proxy) often terminates SSL/TLS for everything behind it. The long version depends on your landscape’s topology, and this page walks through it.
Step 1: Work out where TLS actually terminates in your landscape
This is the question that decides everything else. Draw (or picture) your landscape and ask, for each hostname a browser or external system connects to, which SAP component is the one actually presenting the certificate:
- Web Dispatcher (or another reverse proxy) fronts everything. If all external HTTPS traffic hits Web Dispatcher first, and it routes internally to your ABAP, Java, and other backend systems over a private network, Web Dispatcher is usually the only place that needs a publicly trusted certificate. Internal hops behind it commonly use a private/internal CA, or no separate certificate at all – see our Web Dispatcher installation guide.
- Individual systems are reached directly. If ECC/S4HANA, NetWeaver AS Java, or a cloud system like CPI are reachable on their own hostnames – not just through Web Dispatcher – each of those needs its own certificate. This is common for system-to-system integration traffic, B2B partner connections, or landscapes without a single front door.
- Mixed setup. Most real landscapes are a mix: Web Dispatcher for user-facing traffic, plus a handful of systems (PI/PO, CPI) that talk directly to external partners or cloud services on their own certificates. Map each externally-reachable hostname individually rather than assuming one certificate covers the landscape.
Once you know which hostnames actually need a publicly trusted certificate, the rest is just picking the right shape and validation level for each one.
Step 2: Pick the domain coverage
Certificates aren’t one-size-fits-all – they differ in how many hostnames a single certificate covers:
- Single-domain – covers exactly one hostname (e.g.
webdisp.yourcompany.com). The simplest option, and the right one if only one hostname needs covering. - Wildcard – covers one hostname plus every direct subdomain at that level (e.g.
*.yourcompany.comcoversdev-erp,qa-erp, andprod-erpsubdomains alike). Worth it when several SAP systems or environments share a domain suffix and you’d rather manage one certificate than several – common where dev/QA/production instances of the same system each get their own subdomain. - Multi-domain (SAN/UCC) – covers a list of specific, unrelated hostnames on one certificate (e.g.
webdisp.yourcompany.comandpi.yourcompany.comtogether). Useful when you have a handful of distinct hostnames across different domains or systems and don’t want a full wildcard’s broader coverage.
A wildcard is usually the practical choice for a landscape with multiple environments under one domain; a multi-domain/SAN certificate suits a small, fixed set of distinct hostnames; single-domain is right when there’s genuinely just one.
Step 3: Pick the validation level
Certificate authorities validate you differently depending on the certificate type, and it affects price and issuance time, not just trust:
- DV (Domain Validated) – confirms you control the domain, nothing more. Issued in minutes. This is what most SAP landscapes need: the padlock and encryption are identical to OV/EV, and major browsers stopped visually distinguishing validation levels years ago.
- OV (Organization Validated) – confirms your organization’s legal identity as well as domain control. Takes longer to issue (days, not minutes) because the CA verifies business registration details. Worth it if your organization’s compliance policy specifically requires organization-validated certificates, or if a partner/auditor asks for one.
- EV (Extended Validation) – the most rigorous validation. Historically came with a green address-bar indicator; that visual distinction has been removed from every major browser, so the practical benefit today is mainly meeting a specific compliance or contractual requirement rather than anything a user sees.
Unless a policy or partner requirement says otherwise, DV is the sensible default for internal and external SAP endpoints alike – it’s what most of our own certificate options are built around.
Why do similar-looking certificates cost different amounts?
It’s a fair question – a $10 certificate and a $650 certificate both show the same padlock. The price difference comes down to two things, neither of which is “quality”:
The brand name isn’t a trust signal. Comodo and Sectigo aren’t competing certificate authorities – Comodo CA rebranded as Sectigo in 2018. “PositiveSSL” is simply the legacy name still used for the entry-level DV product line; certificates under either name come from the same CA, the same root of trust, and the same encryption. Don’t pick between them expecting a difference in security.
Coverage and validation level drive the price. A single-domain DV certificate is the cheapest because it covers one hostname and only confirms you control that domain. Wildcard and multi-domain certificates cost more because they cover more hostnames. OV (Organization Validated) certificates cost more again because the CA also verifies your organization’s legal registration – which is also where the CA’s own financial warranty jumps, from $10,000 on the DV line to $1,000,000 on OV:
| Certificate | Coverage | Validation | From | CA warranty |
|---|---|---|---|---|
| Comodo PositiveSSL | Single domain | DV | $10.44/yr | $10,000 |
| Comodo PositiveSSL Multi-Domain | Several specific domains | DV | $27.13/yr | $10,000 |
| Comodo PositiveSSL Wildcard | Domain + all subdomains | DV | $115.45/yr | $10,000 |
| Sectigo Multi-Domain/UCC Wildcard | Several domains + subdomains | DV | $346.68/yr | $500,000 |
| Sectigo OV SSL | Single domain | OV | $133.54/yr | $1,000,000 |
| Sectigo OV Wildcard | Domain + all subdomains | OV | $666.29/yr | $1,000,000 |
That warranty is a payout from the CA to a relying party if they mis-issue a certificate – it isn’t consumer protection for you as the buyer. For that, every certificate on this site comes with our own 30-day money-back guarantee.
Step 4: Match it to your SAP component and go install it
Once you know the hostname(s), coverage, and validation level you need, buy the certificate and head to the guide for whichever SAP component is actually presenting it:
- SAP Web Dispatcher – PSE-based, via
sapgenpse. - ECC & S/4HANA (ABAP/STRUST) – via transaction STRUST.
- NetWeaver AS Java / PI-PO – via NWA Key Storage.
- SAP Integration Suite (CPI) – via Custom Domain Manager or the tenant Keystore.
Each guide also has a companion page on automating renewal, worth reading at the same time – see the full guides list.
Still not sure?
If your landscape’s topology doesn’t map cleanly onto the above – multiple Web Dispatchers, a mix of on-premise and cloud, or a partner integration with its own requirements – it’s worth getting that mapped out properly before buying anything, since the wrong shape of certificate (single-domain where you needed a SAN, DV where a partner insists on OV) means buying again. Let us know what your landscape looks like and we’ll point you at the right option.