A single-brand website needs one certificate and a reminder to renew it. A marketplace is different. Vendors get their own subdomains, some bring custom domains, buyers upload media from many sources, and payment providers send callbacks to endpoints that must never fail. This SSL installation checklist for multi-vendor marketplaces walks through each decision in the order you will meet it, so nothing is left to chance on launch day or at the first renewal.
The guidance below is practical rather than prescriptive, and your stack will shape the details. If you would rather have an engineer plan and install this for you, our server hardening and SSL installation service covers certificate design, installation and monitoring as one scoped piece of work.
Why marketplaces need a different SSL plan
Four things make marketplace certificates harder than ordinary ones.
- Many hostnames: every vendor storefront such as vendor-name.yourmarketplace.com needs to be covered, and new vendors join continuously.
- Custom vendor domains: vendors who point their own domain at your platform need a certificate you do not control the DNS for.
- Third-party traffic: payment gateways, shipping providers and tax services call your servers, and they will reject a broken or incomplete chain.
- Untrusted content: vendors upload images, videos and descriptions that can quietly reference insecure resources.
A plan that ignores any of these tends to fail in a visible way: a browser warning on a vendor page, a payment confirmation that never arrives, or a storefront that goes dark because one renewal was missed.
Step 1: Choose wildcard, SAN or both
The first decision is certificate type. Both options are valid, and many marketplaces use a mix.
Wildcard certificates
A wildcard certificate covers every first-level subdomain under your domain. For vendor storefronts on a pattern like store.yourmarketplace.com, one certificate handles every current and future vendor with no extra issuance. The trade-off is that wildcard validation normally requires a DNS challenge, so your renewal automation needs access to your DNS provider. It also covers only one level, so a name like shop.vendor.yourmarketplace.com would not be included.
SAN (multi-domain) certificates
A SAN certificate lists each hostname explicitly. This suits a fixed set of platform domains, for example your main site, API, admin panel and media host. It is less suited to hundreds of changing vendor names, because every change means reissuing the certificate.
Per-vendor certificates for custom domains
When a vendor connects their own domain, the cleanest approach is to issue an individual certificate for that hostname once DNS points to you, usually by an automated HTTP challenge. Build this into onboarding so a vendor is never live on plain HTTP while waiting for a manual step.
The marketplace SSL installation checklist
Use this list as a working document. Each item is something a person or a script should verify before going live.
- Inventory every hostname: main site, API, admin, media or asset host, vendor subdomain pattern, staging, and any webhook endpoints.
- Pick certificate types: wildcard for vendor subdomains, SAN or single certificates for fixed platform names, individual certificates for custom vendor domains.
- Confirm validation method: DNS challenge for wildcards, HTTP challenge for individual hostnames, and make sure the credentials used are scoped as narrowly as your DNS provider allows.
- Install the full chain: serve the leaf and intermediate certificates together, not the leaf alone, since some API clients are stricter than browsers.
- Disable obsolete protocols: allow current TLS versions only and remove weak ciphers.
- Redirect HTTP to HTTPS: at the edge, with no exceptions for vendor pages or checkout.
- Automate renewal: use an ACME client or your platform's managed certificates, and test a renewal in staging before relying on it.
- Reload services after renewal: a renewed file on disk does nothing if the web server never picks it up.
- Handle mixed content: scan pages and vendor uploads for http:// references and fix or rewrite them.
- Test payment and webhook endpoints: confirm every callback URL works over HTTPS with the full chain.
- Enable HSTS carefully: start with a short duration and expand after you have verified everything.
- Verify CDN and load balancer termination: check both the edge certificate and the connection to your origin.
- Set up expiry monitoring: alerts for every certificate, with more than one recipient.
- Document the process: who owns renewals, where credentials live and how to recover.
Certificate options at a glance
| Option | Best for | Main benefit | Main risk |
|---|---|---|---|
| Wildcard certificate | Vendor storefronts on subdomains of your own domain | New vendors are covered immediately with no reissue | DNS challenge needed; a leaked private key affects every subdomain |
| SAN certificate | A fixed list of platform hostnames | One certificate for several named services | Reissue needed whenever the list changes |
| Per-vendor certificate | Vendors using their own custom domains | Isolated, so one vendor problem does not affect others | Needs automation at scale; fails if vendor DNS is wrong |
| CDN-managed certificate | Public traffic served through a CDN | Edge handles issuance and renewal | Origin connection still needs its own valid certificate |
| Load balancer certificate | Termination before traffic reaches app servers | Central place to manage and renew | Internal hops may be left unencrypted if not planned |
No row is universally right. A typical marketplace ends up with a wildcard for subdomains, a small number of named certificates for platform services, and automated per-vendor certificates for custom domains.
Auto-renewal that actually works
Most outages caused by expired certificates happen because renewal was automated but never verified. Three habits prevent that.
- Test the whole path: issuance, installation and service reload should all be exercised, not just the download.
- Separate renewal from deployment: if you run several servers behind a balancer, make sure every node receives the new certificate, not only the one that ran the renewal.
- Plan for failure: a DNS provider outage or a changed API token can silently break the next run. Alert on failed renewals, not just on approaching expiry dates.
For wildcards, keep the DNS credential limited to the records needed for validation where your provider supports it. Our SSL and server hardening engineers usually set up renewal hooks, reload steps and failure alerts together so they behave as one system.
Mixed content from vendor-uploaded media
This is the problem unique to marketplaces. A vendor pastes a product description containing an image tag pointing at an http:// address, or links a video from a site that has no certificate. Your page loads over HTTPS but the browser blocks or flags the insecure resource, and the storefront looks broken or untrustworthy at the worst possible moment.
- Host uploads yourself: store media on your own domain or CDN so every file is served securely.
- Sanitise on input: rewrite or reject http:// references in descriptions and rich text fields.
- Use a content security policy: an upgrade-insecure-requests directive can help, though it is a safety net and not a substitute for clean data.
- Scan existing listings: older vendor content may contain insecure links that predate your HTTPS migration.
Payment callbacks and webhook endpoints
Payment gateways, shipping partners and tax tools call your server to confirm orders and payouts. These callers often use stricter TLS clients than browsers, and a missing intermediate certificate can cause them to fail while your site appears perfectly fine in a browser.
- Test each callback URL with a command-line client, not just a browser.
- Confirm the endpoint is not behind a redirect that changes the host or drops the request body.
- Keep webhook endpoints on a stable hostname covered by a long-lived, monitored certificate.
- Verify that your firewall or bot protection does not block the provider's requests after you change TLS settings.
- Log failed deliveries so a lapse is noticed in hours, not at the next payout reconciliation.
HSTS without locking yourself out
HTTP Strict Transport Security tells browsers to use HTTPS only. It is valuable, but it is also hard to undo once browsers have cached it. For a marketplace with changing vendor domains, roll it out in stages.
- Begin with a short max-age and check every subdomain, including old ones.
- Confirm that every vendor subdomain can serve a valid certificate before adding the includeSubDomains directive.
- Apply it to custom vendor domains only if you control their certificates end to end.
- Consider preload only after a long period of stable operation, since removal is slow.
CDN and load balancer termination
Many marketplaces terminate TLS at a CDN or load balancer, then forward traffic to application servers. That is a sound design, but it creates two connections to secure, not one.
- Edge to visitor: a valid public certificate covering all served hostnames.
- Edge to origin: use full verification mode where available, with a valid origin certificate. Avoid modes that accept any certificate, as they hide real problems.
- Forwarded headers: make sure the application knows the original request was HTTPS, or it may generate http:// links and redirects.
- Consistent configuration: every load balancer node should carry the same certificate set.
Renewal monitoring and ownership
Monitoring is what turns a good setup into a dependable one. Track the expiry date of each live certificate from the outside, the way a visitor sees it, not just from the files on your server. Send alerts to a shared mailbox and a team channel so the loss of one employee does not leave renewals unwatched. Review the list whenever a vendor connects or removes a custom domain, and write down who is responsible. Our server hardening service includes this kind of ongoing monitoring when you want it handled for you.
Why Companies Choose CloudHouse for SSL Installation
Teams work with CloudHouse because we plan the certificate design before touching a server, stay available for support after launch and give transparent, itemised quotes so you can see what each part of the work involves. We document the renewal process so your own team can understand and own it afterwards.
Conclusion
For a multi-vendor marketplace, SSL installation is an ongoing system of certificate choices, automated renewal, clean content, reliable callbacks and monitoring. Work through the checklist above, choose wildcard, SAN and per-vendor certificates deliberately, and treat renewal as something you test, not something you assume. If you want an engineer to plan and install it, visit our SSL installation and server hardening page and request an itemised quote.
