{"id":3625,"date":"2025-12-28T22:43:47","date_gmt":"2025-12-28T19:43:47","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/wildcard-ssl-vs-san-certificates-which-one-fits-your-e-commerce-setup\/"},"modified":"2025-12-28T22:43:47","modified_gmt":"2025-12-28T19:43:47","slug":"wildcard-ssl-vs-san-certificates-which-one-fits-your-e-commerce-setup","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/wildcard-ssl-vs-san-certificates-which-one-fits-your-e-commerce-setup\/","title":{"rendered":"Wildcard SSL vs SAN Certificates: Which One Fits Your E\u2011Commerce Setup?"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Your_SSL_Strategy_Matters_for_ECommerce_and_MultiDomain_Setups\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Your SSL Strategy Matters for E\u2011Commerce and Multi\u2011Domain Setups<\/a><\/li><li><a href=\"#Wildcard_SSL_Certificates_in_Plain_Language\"><span class=\"toc_number toc_depth_1\">2<\/span> Wildcard SSL Certificates in Plain Language<\/a><ul><li><a href=\"#When_a_Wildcard_SSL_Fits_Well\"><span class=\"toc_number toc_depth_2\">2.1<\/span> When a Wildcard SSL Fits Well<\/a><\/li><li><a href=\"#Wildcard_SSL_Limitations_and_Risks\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Wildcard SSL Limitations and Risks<\/a><\/li><\/ul><\/li><li><a href=\"#SAN_MultiDomain_Certificates_Explained\"><span class=\"toc_number toc_depth_1\">3<\/span> SAN \/ Multi\u2011Domain Certificates Explained<\/a><ul><li><a href=\"#When_SAN_MultiDomain_Certificates_Shine\"><span class=\"toc_number toc_depth_2\">3.1<\/span> When SAN \/ Multi\u2011Domain Certificates Shine<\/a><\/li><li><a href=\"#Downsides_of_SAN_Certificates\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Downsides of SAN Certificates<\/a><\/li><\/ul><\/li><li><a href=\"#Wildcard_vs_SAN_SidebySide_for_RealWorld_Architectures\"><span class=\"toc_number toc_depth_1\">4<\/span> Wildcard vs SAN: Side\u2011by\u2011Side for Real\u2011World Architectures<\/a><ul><li><a href=\"#Typical_ECommerce_Topologies_and_What_We_Recommend\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Typical E\u2011Commerce Topologies and What We Recommend<\/a><ul><li><a href=\"#Scenario_1_Single_Brand_with_Several_Subdomains\"><span class=\"toc_number toc_depth_3\">4.1.1<\/span> Scenario 1: Single Brand with Several Subdomains<\/a><\/li><li><a href=\"#Scenario_2_Holding_Company_with_Multiple_Stores\"><span class=\"toc_number toc_depth_3\">4.1.2<\/span> Scenario 2: Holding Company with Multiple Stores<\/a><\/li><li><a href=\"#Scenario_3_MultiTenant_SaaS_on_Subdomains\"><span class=\"toc_number toc_depth_3\">4.1.3<\/span> Scenario 3: Multi\u2011Tenant SaaS on Subdomains<\/a><\/li><li><a href=\"#Scenario_4_Shared_Platform_Agency_Clients\"><span class=\"toc_number toc_depth_3\">4.1.4<\/span> Scenario 4: Shared Platform + Agency Clients<\/a><\/li><\/ul><\/li><\/ul><\/li><li><a href=\"#Security_Compliance_and_Operational_Details_You_Shouldnt_Skip\"><span class=\"toc_number toc_depth_1\">5<\/span> Security, Compliance and Operational Details You Shouldn\u2019t Skip<\/a><ul><li><a href=\"#PCIDSS_and_Certificate_Strategy\"><span class=\"toc_number toc_depth_2\">5.1<\/span> PCI\u2011DSS and Certificate Strategy<\/a><\/li><li><a href=\"#Automation_with_ACME_DNS01_vs_HTTP01\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Automation with ACME: DNS\u201101 vs HTTP\u201101<\/a><\/li><li><a href=\"#Key_Isolation_and_Environment_Boundaries\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Key Isolation and Environment Boundaries<\/a><\/li><\/ul><\/li><li><a href=\"#Practical_Decision_Tree_Choosing_Wildcard_SAN_or_Both\"><span class=\"toc_number toc_depth_1\">6<\/span> Practical Decision Tree: Choosing Wildcard, SAN, or Both<\/a><ul><li><a href=\"#Step_1_List_Your_Hostnames\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Step 1: List Your Hostnames<\/a><\/li><li><a href=\"#Step_2_Identify_Grouping_Logic\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Step 2: Identify Grouping Logic<\/a><\/li><li><a href=\"#Step_3_Decide_Certificate_Type_Per_Group\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Step 3: Decide Certificate Type Per Group<\/a><\/li><li><a href=\"#Step_4_Plan_Automation_and_Renewal\"><span class=\"toc_number toc_depth_2\">6.4<\/span> Step 4: Plan Automation and Renewal<\/a><\/li><\/ul><\/li><li><a href=\"#Hosting_and_Infrastructure_Tips_from_the_dchostcom_Team\"><span class=\"toc_number toc_depth_1\">7<\/span> Hosting and Infrastructure Tips from the dchost.com Team<\/a><ul><li><a href=\"#On_Shared_Hosting\"><span class=\"toc_number toc_depth_2\">7.1<\/span> On Shared Hosting<\/a><\/li><li><a href=\"#On_VPS_or_Dedicated_Servers\"><span class=\"toc_number toc_depth_2\">7.2<\/span> On VPS or Dedicated Servers<\/a><\/li><\/ul><\/li><li><a href=\"#Summary_and_Next_Steps\"><span class=\"toc_number toc_depth_1\">8<\/span> Summary and Next Steps<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Your_SSL_Strategy_Matters_for_ECommerce_and_MultiDomain_Setups\">Why Your SSL Strategy Matters for E\u2011Commerce and Multi\u2011Domain Setups<\/span><\/h2>\n<p>When you run an e\u2011commerce site, a SaaS platform, or manage multiple brands under one roof, \u201cjust enable HTTPS\u201d is no longer enough. The way you structure your SSL\/TLS certificates directly affects security boundaries, automation, operational complexity, and even how fast you can launch new subdomains and microsites. Two options come up again and again in our conversations with customers at dchost.com: <strong>wildcard <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a>s<\/strong> and <strong>SAN (Subject Alternative Name) \/ multi\u2011domain certificates<\/strong>. Both can secure many hostnames, but they behave very differently in real\u2011world architectures.<\/p>\n<p>In this article, we\u2019ll walk through how each certificate type really works, where they shine, where they hurt, and how we decide between them when designing e\u2011commerce and multi\u2011domain setups for our own customers. By the end, you\u2019ll have a clear, practical framework to answer a simple but important question: <strong>\u201cShould I use a wildcard SSL, a SAN certificate, or a mix of both for my environment?\u201d<\/strong><\/p>\n<h2><span id=\"Wildcard_SSL_Certificates_in_Plain_Language\">Wildcard SSL Certificates in Plain Language<\/span><\/h2>\n<p>A <strong>wildcard SSL certificate<\/strong> secures one domain and all of its first\u2011level subdomains. If your certificate is issued for <code>*.example.com<\/code>, it can cover <code>www.example.com<\/code>, <code>shop.example.com<\/code>, <code>api.example.com<\/code>, and <code>cdn.example.com<\/code> with a single cert and private key. It will not cover <code>example.com<\/code> itself (that\u2019s a separate hostname) unless the certificate is issued for both <code>example.com<\/code> and <code>*.example.com<\/code>. It also will not cover <code>store.eu.example.com<\/code> because that\u2019s a <em>second\u2011level<\/em> subdomain.<\/p>\n<p>The biggest reason teams love wildcards is flexibility. You can create new subdomains quickly without touching your certificate: just add DNS and web server configuration, and you\u2019re done. This is especially useful for architectures where you spin up subdomains frequently\u2014think <code>tenant1.example.com<\/code>, <code>tenant2.example.com<\/code> for a multi\u2011tenant SaaS, or <code>campaign\u2011xyz.example.com<\/code> for marketing landing pages.<\/p>\n<p>Modern wildcard certificates are usually issued and renewed via ACME automation (for example, Let\u2019s Encrypt or commercial CAs) using the DNS\u201101 challenge. We\u2019ve covered the operational side of this in detail in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/lets-encrypt-wildcard-ssl-otomasyonu-dns-01-ile-cpanel-plesk-ve-nginxte-zahmetsiz-kurulum-ve-yenileme-nasil-yapilir\/\">hands\u2011off Let\u2019s Encrypt wildcard SSL automation with DNS\u201101<\/a>, including cPanel, Plesk, and Nginx examples.<\/p>\n<h3><span id=\"When_a_Wildcard_SSL_Fits_Well\">When a Wildcard SSL Fits Well<\/span><\/h3>\n<p>From our experience at dchost.com, wildcard SSLs work particularly well when:<\/p>\n<ul>\n<li>You have <strong>one main brand\/domain<\/strong> (for example, <code>example.com<\/code>) and many subdomains tied to that brand.<\/li>\n<li>Your infrastructure team is comfortable with <strong>DNS\u2011based ACME automation<\/strong> and can integrate it into your DNS provider or hosting panel.<\/li>\n<li>You want to <strong>avoid certificate changes<\/strong> every time marketing launches a new subdomain.<\/li>\n<li>You run a <strong>multi\u2011tenant architecture on subdomains<\/strong> (e.g., <code>customer\u2011name.example.com<\/code>), where all tenants live under the same parent domain.<\/li>\n<\/ul>\n<p>In these situations, a single wildcard certificate can reduce certificate management overhead dramatically.<\/p>\n<h3><span id=\"Wildcard_SSL_Limitations_and_Risks\">Wildcard SSL Limitations and Risks<\/span><\/h3>\n<p>Wildcard SSLs are powerful, but they come with trade\u2011offs you should consider carefully:<\/p>\n<ul>\n<li><strong>Broader blast radius on key compromise:<\/strong> If the private key of your wildcard certificate leaks, <em>every<\/em> subdomain under that wildcard is at risk. For high\u2011security environments, this is a serious concern.<\/li>\n<li><strong>No coverage for unrelated domains:<\/strong> A wildcard issued for <code>*.example.com<\/code> cannot secure <code>example.net<\/code>, <code>brand2.com<\/code>, or <code>api.partner.example.org<\/code>. It\u2019s strictly one domain + subdomains.<\/li>\n<li><strong>Not ideal where strict isolation is needed:<\/strong> If you want strong separation between environments (for example, <code>dev.example.com<\/code>, <code>staging.example.com<\/code>, and <code>prod.example.com<\/code> on different servers with different security policies), sharing a single wildcard key across all of them may conflict with internal security guidelines.<\/li>\n<li><strong>Policy constraints:<\/strong> Some organizations or auditors prefer to avoid wildcards for high\u2011risk systems, or require extra controls (HSM storage, short lifetimes, limited scope) when they\u2019re used.<\/li>\n<\/ul>\n<p>If you\u2019re still deciding between validation levels (DV, OV, EV) and how wildcard fits into that picture, it\u2019s worth reading our detailed comparison of <a href=\"https:\/\/www.dchost.com\/blog\/en\/dv-ov-ev-ve-wildcard-ssl-arasinda-kaybolmadan-e%e2%80%91ticaret-ve-saaste-hangi-sertifika-ne-zaman\/\">DV vs OV vs EV vs wildcard SSL for e\u2011commerce and SaaS<\/a>.<\/p>\n<h2><span id=\"SAN_MultiDomain_Certificates_Explained\">SAN \/ Multi\u2011Domain Certificates Explained<\/span><\/h2>\n<p>A <strong>SAN (Subject Alternative Name) or multi\u2011domain certificate<\/strong> is designed to secure <em>multiple distinct hostnames<\/em> in a single certificate. Instead of a wildcard pattern, you explicitly list each hostname in the certificate\u2019s SAN extension. For example, a single SAN cert might cover:<\/p>\n<ul>\n<li><code>example.com<\/code><\/li>\n<li><code>www.example.com<\/code><\/li>\n<li><code>shop.example.com<\/code><\/li>\n<li><code>example.net<\/code><\/li>\n<li><code>brand\u2011store.com<\/code><\/li>\n<\/ul>\n<p>All of these hostnames are baked into one certificate and share the same private key. You can mix root domains and subdomains, even across different TLDs. This makes SAN certificates attractive when you want to manage several brands or projects together\u2014but don\u2019t want a separate certificate for each.<\/p>\n<p>In many control panels and CA dashboards, you\u2019ll see these marketed as \u201cmulti\u2011domain\u201d or \u201cUCC (Unified Communications Certificates)\u201d rather than SAN certificates, but technically they\u2019re the same concept: the list of hostnames lives in the SAN extension.<\/p>\n<h3><span id=\"When_SAN_MultiDomain_Certificates_Shine\">When SAN \/ Multi\u2011Domain Certificates Shine<\/span><\/h3>\n<p>We reach for SAN certificates primarily in scenarios like these:<\/p>\n<ul>\n<li><strong>Multiple brands, one team:<\/strong> A digital agency or holding group manages ten different e\u2011commerce sites like <code>brand1.com<\/code>, <code>brand2.com<\/code>, <code>brand3.com<\/code>, all hosted on the same infrastructure.<\/li>\n<li><strong>One gateway or load balancer for many domains:<\/strong> Your edge layer (Nginx, HAProxy, or a reverse proxy) terminates TLS for several domains and routes traffic internally to different backends.<\/li>\n<li><strong>Tight certificate limits or rate limits:<\/strong> When ACME or your CA has per\u2011domain or per\u2011account issuance limits, consolidating into one SAN cert can help you stay below those thresholds.<\/li>\n<li><strong>Legacy environments:<\/strong> On some older systems where automation is harder, having fewer certificates to track and renew can be a practical compromise.<\/li>\n<\/ul>\n<p>For many of our customers running a few medium\u2011traffic stores on the same <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> at dchost.com, a SAN certificate can be a nice \u201cone cert, many sites\u201d approach\u2014especially if automation is centralised.<\/p>\n<h3><span id=\"Downsides_of_SAN_Certificates\">Downsides of SAN Certificates<\/span><\/h3>\n<p>Multi\u2011domain certificates also have trade\u2011offs you should be aware of:<\/p>\n<ul>\n<li><strong>All domains share one key and expiry date:<\/strong> If you need to revoke the certificate because one domain is compromised, <em>every<\/em> domain on that SAN certificate is affected.<\/li>\n<li><strong>Operational friction for changes:<\/strong> Adding or removing a single hostname requires <strong>reissuing<\/strong> and redeploying the certificate everywhere it\u2019s used. That\u2019s more moving parts compared to spinning up a new standalone DV cert.<\/li>\n<li><strong>Privacy and information leakage:<\/strong> Anyone inspecting the certificate can see all hostnames listed in the SAN. If you don\u2019t want to publicly expose internal hostnames or future brands, this can be a problem.<\/li>\n<li><strong>Certificate size and handshake overhead:<\/strong> Very large SAN lists slightly increase handshake size. For most medium setups this is negligible, but at very high scale it can matter.<\/li>\n<\/ul>\n<p>Because of these points, we rarely use a single huge SAN certificate for \u201ceverything\u201d. Instead, we group hostnames logically\u2014for example, one SAN for all public marketing sites, another for staging domains, and separate certs for critical payment endpoints.<\/p>\n<h2><span id=\"Wildcard_vs_SAN_SidebySide_for_RealWorld_Architectures\">Wildcard vs SAN: Side\u2011by\u2011Side for Real\u2011World Architectures<\/span><\/h2>\n<p>Both wildcard and SAN certificates let you cover multiple hostnames. The key difference is <strong>how<\/strong> they group those hostnames and what happens operationally when something changes. Here\u2019s a concise comparison based on typical e\u2011commerce and multi\u2011site setups we see at dchost.com.<\/p>\n<table>\n<thead>\n<tr>\n<th>Aspect<\/th>\n<th>Wildcard SSL<\/th>\n<th>SAN \/ Multi\u2011Domain SSL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>What it covers<\/td>\n<td>One domain + all first\u2011level subdomains (e.g. <code>*.example.com<\/code>)<\/td>\n<td>Explicit list of hostnames (e.g. <code>example.com<\/code>, <code>brand2.com<\/code>, <code>shop.example.net<\/code>)<\/td>\n<\/tr>\n<tr>\n<td>Best for<\/td>\n<td>One brand with many subdomains; multi\u2011tenant on subdomains<\/td>\n<td>Multiple brands\/domains on same infrastructure<\/td>\n<\/tr>\n<tr>\n<td>Adding a new subdomain<\/td>\n<td>No cert change needed if it matches the wildcard<\/td>\n<td>Requires reissue if the new hostname isn\u2019t already in SAN list<\/td>\n<\/tr>\n<tr>\n<td>Security blast radius<\/td>\n<td>Key compromise affects every subdomain under the wildcard<\/td>\n<td>Key compromise affects all SAN hostnames; usually fewer per cert<\/td>\n<\/tr>\n<tr>\n<td>Isolation between brands<\/td>\n<td>Not possible (wildcard is single brand only)<\/td>\n<td>Possible by grouping brands into different SAN certs<\/td>\n<\/tr>\n<tr>\n<td>Automation<\/td>\n<td>Ideal with DNS\u201101 ACME; one automation flow per domain<\/td>\n<td>Good with ACME too, but SAN changes force full reissue<\/td>\n<\/tr>\n<tr>\n<td>Visibility of hostnames<\/td>\n<td>Reveals base domain and wildcard pattern<\/td>\n<td>Reveals every exact hostname in the SAN list<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3><span id=\"Typical_ECommerce_Topologies_and_What_We_Recommend\">Typical E\u2011Commerce Topologies and What We Recommend<\/span><\/h3>\n<p>Let\u2019s map this to a few common architectures we help customers design.<\/p>\n<h4><span id=\"Scenario_1_Single_Brand_with_Several_Subdomains\">Scenario 1: Single Brand with Several Subdomains<\/span><\/h4>\n<p>Example hostnames:<\/p>\n<ul>\n<li><code>example.com<\/code> (main store, WooCommerce\/Magento\/PrestaShop)<\/li>\n<li><code>api.example.com<\/code> (mobile app \/ SPA backend)<\/li>\n<li><code>cdn.example.com<\/code> (static assets)<\/li>\n<li><code>admin.example.com<\/code> (backoffice)<\/li>\n<li><code>img.example.com<\/code> (media offload)<\/li>\n<\/ul>\n<p><strong>Good fit:<\/strong> A wildcard (plus optionally the base domain in the same cert) is usually ideal here. It keeps things simple as you add more subdomains. Combine it with a solid TLS configuration and proper redirects as described in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpse-gecis-rehberi-301-yonlendirme-hsts-ve-seoyu-korumak\/\">full HTTPS migration guide with 301 redirects and HSTS<\/a>.<\/p>\n<h4><span id=\"Scenario_2_Holding_Company_with_Multiple_Stores\">Scenario 2: Holding Company with Multiple Stores<\/span><\/h4>\n<p>Example hostnames:<\/p>\n<ul>\n<li><code>brand1.com<\/code><\/li>\n<li><code>brand2.com<\/code><\/li>\n<li><code>brand3.com<\/code><\/li>\n<\/ul>\n<p>All three stores share the same application stack on one or more VPS\/dedicated servers at dchost.com.<\/p>\n<p><strong>Good fit:<\/strong> A SAN certificate that includes <code>brand1.com<\/code>, <code>www.brand1.com<\/code>, <code>brand2.com<\/code>, <code>brand3.com<\/code>, etc. This way your edge proxy terminates TLS for all brands with one cert. For stricter isolation, you might use one SAN per brand family or per environment (production vs staging).<\/p>\n<h4><span id=\"Scenario_3_MultiTenant_SaaS_on_Subdomains\">Scenario 3: Multi\u2011Tenant SaaS on Subdomains<\/span><\/h4>\n<p>Example hostnames:<\/p>\n<ul>\n<li><code>tenant1.example.com<\/code><\/li>\n<li><code>tenant2.example.com<\/code><\/li>\n<li><code>tenant3.example.com<\/code><\/li>\n<\/ul>\n<p><strong>Good fit:<\/strong> A wildcard for <code>*.example.com<\/code> is almost always the cleanest choice, especially when combined with automated issuance and renewal using DNS\u201101. If you also support \u201cbring your own domain\u201d for customers, those customer domains will usually be handled via separate SAN or individual certificates, not the wildcard.<\/p>\n<h4><span id=\"Scenario_4_Shared_Platform_Agency_Clients\">Scenario 4: Shared Platform + Agency Clients<\/span><\/h4>\n<p>Example hostnames:<\/p>\n<ul>\n<li><code>client\u2011a.com<\/code><\/li>\n<li><code>client\u2011b.com<\/code><\/li>\n<li><code>client\u2011c.net<\/code><\/li>\n<\/ul>\n<p>Each client has their own domain, but you host them on a shared stack.<\/p>\n<p><strong>Good fit:<\/strong> A SAN certificate per cluster (for example, a SAN for all production sites on one cluster) often balances simplicity and isolation. For high\u2011value e\u2011commerce clients, we sometimes recommend a dedicated certificate per customer domain so that revocation or key replacement doesn\u2019t affect others.<\/p>\n<h2><span id=\"Security_Compliance_and_Operational_Details_You_Shouldnt_Skip\">Security, Compliance and Operational Details You Shouldn\u2019t Skip<\/span><\/h2>\n<p>Once you\u2019ve chosen between wildcard and SAN (or a combination), you still need to integrate that choice into your overall security and compliance posture. For e\u2011commerce and payment processing, that usually means thinking about PCI\u2011DSS, key management, and automation.<\/p>\n<h3><span id=\"PCIDSS_and_Certificate_Strategy\">PCI\u2011DSS and Certificate Strategy<\/span><\/h3>\n<p>If your store touches card data (or even if you only use a redirect\/hosted payment page), you should understand how your certificate structure interacts with PCI\u2011DSS scoping and segmentation. While PCI\u2011DSS doesn\u2019t ban wildcard or SAN certificates, auditors care about:<\/p>\n<ul>\n<li><strong>Key management:<\/strong> Where private keys are stored, who can access them, and how quickly you can revoke and replace them.<\/li>\n<li><strong>Segmentation:<\/strong> Whether non\u2011cardholder parts of your infrastructure share keys with systems in scope.<\/li>\n<li><strong>Logging and monitoring:<\/strong> Whether TLS terminations are monitored for changes and anomalies.<\/li>\n<\/ul>\n<p>We go deeper into hosting\u2011side responsibilities in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/e%e2%80%91ticarette-pci-dssi-dert-etmeden-nasil-uyumlu-kalirsin-hosting-tarafinda-gercekten-ne-yapmak-gerekir\/\">PCI\u2011DSS for e\u2011commerce without the panic<\/a>. When we design environments for dchost.com customers who need PCI awareness, we often use <strong>multiple smaller certificates<\/strong> (some wildcard, some SAN, some single\u2011domain) to keep the scope of each key as tight as possible.<\/p>\n<h3><span id=\"Automation_with_ACME_DNS01_vs_HTTP01\">Automation with ACME: DNS\u201101 vs HTTP\u201101<\/span><\/h3>\n<p>The real cost of certificates isn\u2019t the purchase price; it\u2019s the human time spent renewing, deploying, and troubleshooting. That\u2019s why we push hard for <strong>ACME automation<\/strong> (Let\u2019s Encrypt or commercial CAs) on our hosting, VPS, and dedicated servers.<\/p>\n<ul>\n<li><strong>Wildcard + ACME:<\/strong> Almost always uses <strong>DNS\u201101<\/strong>. Your automation tool (e.g. acme.sh, certbot) creates a TXT record in DNS, proves domain control, and issues\/renews the wildcard. This is extremely powerful but requires access to your DNS API. We\u2019ve documented real\u2011world setups in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/acme-challenge-turleri-derinlemesine-http%e2%80%9101-dns%e2%80%9101-ve-tls%e2%80%91alpn%e2%80%9101-ne-zaman-hangisi\/\">ACME challenges deep dive (HTTP\u201101 vs DNS\u201101 vs TLS\u2011ALPN\u201101)<\/a>.<\/li>\n<li><strong>SAN + ACME:<\/strong> Can use <strong>HTTP\u201101<\/strong> if all domains point to the same web server or proxy; or DNS\u201101 if you want more flexibility. Renewals are automatic, but remember: adding a new hostname still requires reissue.<\/li>\n<\/ul>\n<p>If you\u2019re unsure whether to stay fully on Let\u2019s Encrypt or mix in paid certificates, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ucretsiz-lets-encrypt-mi-kurumsal-ssl-sertifikasi-mi-e%e2%80%91ticaret-ve-kurumsal-siteler-icin-yol-haritasi\/\">Let\u2019s Encrypt vs commercial SSL for e\u2011commerce and enterprise<\/a> walks through realistic decision points.<\/p>\n<h3><span id=\"Key_Isolation_and_Environment_Boundaries\">Key Isolation and Environment Boundaries<\/span><\/h3>\n<p>Regardless of certificate type, define clear rules for where keys can live:<\/p>\n<ul>\n<li><strong>Separate keys for prod, staging, dev:<\/strong> Don\u2019t reuse the same wildcard across all environments. At minimum, generate separate certs per environment.<\/li>\n<li><strong>Limit key sharing across servers:<\/strong> It\u2019s common to share one cert across a cluster (load balancers, web servers), but avoid copying the same wildcard to completely unrelated systems.<\/li>\n<li><strong>Rotate keys during sensitive changes:<\/strong> After major incidents, staff changes, or hosting migrations, consider re\u2011issuing your certificates with fresh keys.<\/li>\n<\/ul>\n<p>At dchost.com, our team usually recommends a structure like this: one wildcard for production subdomains, one for staging, plus separate SAN or single\u2011domain certs for edge cases (admin panels, partner integrations, or customer\u2011specific domains).<\/p>\n<h2><span id=\"Practical_Decision_Tree_Choosing_Wildcard_SAN_or_Both\">Practical Decision Tree: Choosing Wildcard, SAN, or Both<\/span><\/h2>\n<p>Let\u2019s turn all of this into a concrete, step\u2011by\u2011step decision process you can apply to your own project.<\/p>\n<h3><span id=\"Step_1_List_Your_Hostnames\">Step 1: List Your Hostnames<\/span><\/h3>\n<p>Write down every hostname you need to secure, grouped by environment:<\/p>\n<ul>\n<li>Production: <code>example.com<\/code>, <code>www.example.com<\/code>, <code>api.example.com<\/code>, <code>cdn.example.com<\/code><\/li>\n<li>Staging: <code>staging.example.com<\/code>, <code>api.staging.example.com<\/code><\/li>\n<li>Other brands: <code>brand2.com<\/code>, <code>www.brand2.com<\/code><\/li>\n<li>Customer domains: <code>shop.customer\u2011a.com<\/code>, <code>store.customer\u2011b.com<\/code><\/li>\n<\/ul>\n<p>As you do this, mark which ones share the same infrastructure and TLS termination point (same load balancer or web server).<\/p>\n<h3><span id=\"Step_2_Identify_Grouping_Logic\">Step 2: Identify Grouping Logic<\/span><\/h3>\n<p>Next, group hostnames based on:<\/p>\n<ul>\n<li><strong>Brand boundaries:<\/strong> Do you want one certificate per brand for marketing reasons or security isolation?<\/li>\n<li><strong>Environment boundaries:<\/strong> Should staging and production ever share a key?<\/li>\n<li><strong>Technical endpoints:<\/strong> Which hostnames terminate on the same proxy or server?<\/li>\n<\/ul>\n<p>This will give you natural certificate \u201cbuckets\u201d. Often you\u2019ll end up with 2\u20136 groups, not dozens.<\/p>\n<h3><span id=\"Step_3_Decide_Certificate_Type_Per_Group\">Step 3: Decide Certificate Type Per Group<\/span><\/h3>\n<p>For each bucket, pick the certificate style that best fits:<\/p>\n<ul>\n<li><strong>Group dominated by one domain + many subdomains?<\/strong> Choose a <strong>wildcard<\/strong> (e.g. <code>*.example.com<\/code>). Optionally add <code>example.com<\/code> as an extra SAN in the same certificate if your CA allows it.<\/li>\n<li><strong>Group containing unrelated domains or multiple brands?<\/strong> Use a <strong>SAN certificate<\/strong> with all required hostnames explicitly listed.<\/li>\n<li><strong>Single high\u2011value hostname<\/strong> (for example, <code>payments.example.com<\/code> or <code>checkout.brand.com<\/code>)? Consider a <strong>dedicated single\u2011domain cert<\/strong> to keep key scope as small as possible.<\/li>\n<\/ul>\n<p>It\u2019s perfectly normal\u2014and often optimal\u2014to use <strong>both wildcard and SAN certificates<\/strong> in the same infrastructure.<\/p>\n<h3><span id=\"Step_4_Plan_Automation_and_Renewal\">Step 4: Plan Automation and Renewal<\/span><\/h3>\n<p>Once the structure is clear, decide how you\u2019ll issue and renew certificates:<\/p>\n<ul>\n<li>On shared hosting or managed panels, enable AutoSSL\/Let\u2019s Encrypt where possible.<\/li>\n<li>On VPS and dedicated servers, integrate ACME clients (acme.sh, certbot, etc.) with your web server and DNS provider.<\/li>\n<li>Document renewal commands and locations of private keys, and test a manual reissue so you\u2019re not debugging under time pressure.<\/li>\n<\/ul>\n<p>If you\u2019re running many domains and worry about rate limits, we\u2019ve written about using SANs and wildcards strategically in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/lets-encrypt-rate-limitlerine-takilmadan-cok-alan-adinda-ssl-san-wildcard-acme-challenge-ve-tatli-stratejiler\/\">avoiding Let\u2019s Encrypt rate limits with SANs, wildcards, and calm ACME automation<\/a>.<\/p>\n<h2><span id=\"Hosting_and_Infrastructure_Tips_from_the_dchostcom_Team\">Hosting and Infrastructure Tips from the dchost.com Team<\/span><\/h2>\n<p>The certificate model you choose should match your hosting architecture. Because dchost.com offers shared hosting, VPS, dedicated servers and colocation, we see all combinations in practice.<\/p>\n<h3><span id=\"On_Shared_Hosting\">On Shared Hosting<\/span><\/h3>\n<p>If you run a single store or a small set of sites on shared hosting:<\/p>\n<ul>\n<li>Take advantage of the panel\u2019s built\u2011in AutoSSL \/ Let\u2019s Encrypt integration.<\/li>\n<li>Use separate certificates per domain unless your provider explicitly supports multi\u2011domain certificates in the UI.<\/li>\n<li>Focus on clean HTTPS redirects and HSTS rather than over\u2011optimising certificate structure.<\/li>\n<\/ul>\n<p>For most small to medium stores, this is enough to stay secure and compliant without manual certificate juggling.<\/p>\n<h3><span id=\"On_VPS_or_Dedicated_Servers\">On VPS or Dedicated Servers<\/span><\/h3>\n<p>Here you have full control\u2014and more responsibility. Our typical approach when deploying e\u2011commerce or multi\u2011brand setups on dchost.com VPS or dedicated servers looks like this:<\/p>\n<ul>\n<li>Terminate TLS on Nginx or HAProxy at the edge.<\/li>\n<li>Use a <strong>wildcard<\/strong> for the main brand\u2019s subdomains on production, another wildcard for staging.<\/li>\n<li>Use one or more <strong>SAN certificates<\/strong> for additional brands that share the same proxy.<\/li>\n<li>Automate all issuance and renewals with ACME, storing certs in a central path and reloading services via systemd hooks.<\/li>\n<\/ul>\n<p>If you colocate your own hardware with us, the same patterns apply; you just have even more flexibility in how you integrate TLS with your application stack and load balancers.<\/p>\n<h2><span id=\"Summary_and_Next_Steps\">Summary and Next Steps<\/span><\/h2>\n<p>Choosing between <strong>wildcard SSL<\/strong> and <strong>SAN (multi\u2011domain) certificates<\/strong> is less about which one is \u201cbetter\u201d and more about how your domains, subdomains, and environments are structured. Wildcards are fantastic when you have one main brand with many subdomains and strong DNS\u201101 automation in place. SAN certificates are ideal when you host multiple brands or domains on the same edge infrastructure and want to keep certificate management centralised.<\/p>\n<p>The sweet spot for serious e\u2011commerce setups is usually a <strong>hybrid approach<\/strong>: wildcard certificates for main brand subdomains, SAN or single\u2011domain certificates for separate brands and high\u2011value endpoints, all glued together with robust ACME automation and clear key\u2011management policies. If you\u2019re also dealing with PCI\u2011DSS, regulatory requirements, or complex multi\u2011region hosting, pairing the right certificate strategy with the right server architecture matters even more.<\/p>\n<p>If you\u2019d like help mapping this to your own environment\u2014whether that\u2019s shared hosting, a high\u2011performance VPS, a dedicated server cluster or colocation\u2014our team at dchost.com can review your domains, traffic patterns and compliance needs, then recommend a concrete wildcard\/SAN plan plus hosting architecture to match. Start by listing your domains and current certificates, and we\u2019ll help you turn that into a clean, scalable TLS strategy.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>\u0130&ccedil;indekiler1 Why Your SSL Strategy Matters for E\u2011Commerce and Multi\u2011Domain Setups2 Wildcard SSL Certificates in Plain Language2.1 When a Wildcard SSL Fits Well2.2 Wildcard SSL Limitations and Risks3 SAN \/ Multi\u2011Domain Certificates Explained3.1 When SAN \/ Multi\u2011Domain Certificates Shine3.2 Downsides of SAN Certificates4 Wildcard vs SAN: Side\u2011by\u2011Side for Real\u2011World Architectures4.1 Typical E\u2011Commerce Topologies and What [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3626,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3625","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3625","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=3625"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3625\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3626"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3625"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3625"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3625"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}