Tecof • September 14, 2026
What Is an SSL Certificate? Why E-commerce Security Depends on It
In Brief
An SSL certificate is a digital identity file in which an independent third party confirms that a domain really belongs to the party claiming it, and it is the key that starts TLS, the protocol encrypting traffic between browser and server. The name "SSL" was retired in 2015 and today's protocol is TLS, but habit still calls the file an SSL certificate. In e-commerce the issue reaches past encryption: your virtual POS application, Google ranking, KVKK compliance and whether a shopper abandons the cart hang on the same file. As of 2026 the question is no longer "should my site have SSL", it is "when my chain, my renewal or my monitoring fails at three in the morning, how many minutes pass before I notice".
Tuesday morning, 09:15. On the analytics screen of a mid-sized home textiles store, a figure that read 340 sessions at this hour yesterday now reads 41. Ad spend is running, the campaign is live, stock is in place. Twelve of the fourteen messages reaching customer service since 08:40 carry one screenshot: "Your connection is not private — NET::ERR_CERT_DATE_INVALID". The certificate expired at 03:00 that night. Automatic renewal had quietly stopped six months earlier, when the server was migrated and the scheduled task was not carried over. The fix took 45 minutes. For a store averaging 118,000 TL in daily revenue, the loss came to roughly 34,000 TL, plus 4,200 TL of wasted Google Ads clicks and three days of depressed conversion. Technical effort: one command. Cost: a week of profit.
The certificate is not the problem. The problem is that it was treated as invisible infrastructure and never wired into a dashboard, an alert channel or a checklist. Most things in e-commerce break loudly. SSL breaks quietly, and only the customer sees it.
What SSL, TLS and HTTPS actually do
One file doing three jobs at once
The certificate has three jobs, and most business owners know only one.
- Encryption: the card number, address and password your customer types become unreadable to anyone in between. Someone capturing traffic on a shared cafe Wi-Fi sees noise.
- Authentication: when you connect to tecof.com, the authority's signature guarantees you reached the real server and not an impostor in the middle. Neither half works without the other.
- Integrity: if data is altered in transit, the browser detects it. Injecting ads at carrier level, or swapping the account number on a payment form, is blocked.
The handshake: what happens in 200 milliseconds
The browser connects and announces which encryption methods it supports. The server picks one and sends its certificate. The browser checks three things: is the signing authority in its trusted root list, are the dates current, does the domain in the certificate match the address bar. If all three pass, the two sides derive a shared session key and the real exchange continues encrypted with it. TLS 1.3 needs one round trip, so a handshake takes 100-200 milliseconds; TLS 1.2 needs two and can double that.
The chain, the intermediate, and the most commonly skipped step
Your certificate does not work alone. A root authority signs an intermediate, and the intermediate signs yours; your server must send both. Desktop Chrome often finds a missing intermediate by itself, the in-app browser on Android does not. So you check from your desktop and conclude everything works, while the mobile users who are 70 percent of your traffic see an error screen. After any installation, run an independent chain test and open the site on a real phone over mobile data.
Certificate types: which one you actually need
The real difference between DV, OV and EV
Three validation levels exist. What separates them is not encryption strength, identical in all three, but how thoroughly the authority investigated you.
| Type | What it verifies | Issue time | Annual cost | Who it suits |
|---|---|---|---|---|
| DV (Domain Validation) | That you control the domain | 2-10 minutes | 0-400 TL | Blogs, small stores |
| OV (Organization Validation) | Domain plus registered legal existence | 1-3 business days | 1,500-4,000 TL | B2B stores |
| EV (Extended Validation) | Domain, company, address, signing authority | 3-10 business days | 4,000-12,000 TL | Finance, high basket values |
| Wildcard | *.yoursite.com — all first-level subdomains | Minutes at DV | 0-6,000 TL | Many subdomains |
| Multi-domain (SAN) | 3-100 domains on one certificate | By type | 1,000-15,000 TL | .com.tr plus .com plus campaigns |
The old sales pitch for EV was the green company name in the address bar. Chrome removed that indicator in 2019 and Firefox followed, so your customer can no longer see any difference between EV and DV. The only rational reason to buy EV today is a buyer or auditor demanding it in a contract. In a store with an average basket of 800 TL, EV adds nothing to conversion.
Wildcard, SAN, or separate certificates
Above three subdomains, a wildcard cuts your management load: one renewal, one file. But if the private key leaks, every subdomain is compromised at once. Keeping payment, admin panel and API outside the wildcard, each with its own certificate, is the sensible arrangement. If you hold your brand on several extensions (yoursite.com and yoursite.com.tr), a multi-domain certificate gives one renewal calendar; a separate free certificate for each through Let's Encrypt is equally valid and more flexible.
Let's Encrypt versus a paid certificate
| Criterion | Let's Encrypt (free) | Paid DV | Paid OV/EV |
|---|---|---|---|
| Encryption strength | Identical | Identical | Identical |
| Browser trust | Full | Full | Full |
| Validity period | 90 days, auto-renewed | Up to 398 days | Up to 398 days |
| Support | Community forum | Phone/ticket, 24 hours | Priority, 4 hours |
| Warranty / insurance | None | 10,000-250,000 USD | 1-2 million USD |
| Accepted for virtual POS applications | Yes | Yes | Yes |
The rule is simple: unless a contract, a bank or an auditor asks for OV or EV, Let's Encrypt is sufficient, and for most stores in Turkey it is the right choice. The one condition is tying the 90-day cycle to automatic renewal. If you plan to renew by hand, buy a paid 398-day certificate — manual renewal means four chances a year to forget. As we noted in our piece on mistakes made when choosing an e-commerce platform, who owns certificate management should be settled at contract stage, not after an outage.
Why SSL is not negotiable in e-commerce
Virtual POS: the first thing the bank looks at
When you apply for a virtual POS in Turkey, the bank or payment institution reviews your site manually. Valid HTTPS is among the first checklist items; next, that the payment page runs over HTTPS; then, that your distance sales agreement, pre-information form, return policy and delivery terms pages are reachable. If those open over plain HTTP or throw mixed-content warnings, the application can be rejected. Availability is checked again when your ETBIS registration — Turkey's e-commerce registry — is verified.
PCI DSS and card data
Card details may never touch your server, moving through the provider's iframe or redirect, as most Turkish stores operate. That does not remove you from PCI DSS scope. Even under SAQ A, the site hosting the payment page must use TLS with weak protocols (SSL 3.0, TLS 1.0, TLS 1.1) disabled. If TLS 1.0 is still enabled, that is a compliance finding and it surfaces in the annual scan.
Browser warnings, KVKK and search ranking
Chrome marks password and card fields on non-HTTPS pages as "Not secure", and where the certificate is invalid it shows a full-page interstitial taking two clicks to pass. Most visitors who see it leave. Turkey's data protection authority lists encryption in transit among its technical measures, and since names, addresses, phone numbers and order histories are personal data, every store taking registrations is in scope. Google has called HTTPS a ranking signal since 2014: not decisive alone, but a tiebreaker. Every improvement you make on the conversion rate side loses its meaning if the visitor meets a warning screen in the first second.
Four problems that appear after installation
Mixed content: what kills the padlock
If your page loads over HTTPS but an image, font or script inside it comes from an HTTP address, the browser removes the padlock. Scripts and stylesheets are blocked outright, and the result is a broken page or an add-to-cart button that does nothing. Frequent sources: http:// image URLs in old product descriptions, hard-coded addresses in theme files, legacy ad or chat snippets. Work in order — bulk-replace http://yoursite.com with https:// in the database, sweep theme and widget code, then close remaining console warnings one by one. If a third-party service still serves only HTTP, replace it.
HSTS: a knife that cuts both ways
HSTS is a header telling the browser to open your domain over HTTPS only. It blocks SSL stripping and trims the initial redirect. Its risk: for the duration of max-age the browser refuses HTTP, so if your certificate breaks, falling back is not an option. Ramp up gradually — 300 seconds, 86400 after a clean week, 31536000 after a month. Do not add includeSubDomains or preload until every subdomain is on HTTPS; leaving the preload list can take months.
Renewal and expiry
Certificate lifetimes keep shrinking. The ceiling was three years in 2015, dropped to 398 days in 2020, and the industry has agreed on a schedule bringing it to 47 days by 2029. Manual renewal stops being a strategy. Even with automation, verify three things: is the renewal task copied during migrations, does the web server actually reload afterwards, and who gets an email when a renewal fails. The third is usually missing — exactly what happened in the opening scene.
SSL during a domain migration
When you move a domain to another provider or the site to a new server, the certificate does not follow. The sequence: bring the site up on the new server, issue the certificate there before touching DNS (Let's Encrypt's DNS validation allows this), then lower the TTL to 300 seconds and switch the record. In reverse order, some visitors land on a certificate-less server while DNS propagates. Keep old-server redirects live 30 days, and confirm both www and non-www appear in the certificate.
Reading error codes and setting up monitoring
The NET::ERR_CERT_* family
| Error code | What it actually means | First move | Typical fix time |
|---|---|---|---|
| ERR_CERT_DATE_INVALID | Expired, or the clock is wrong | Renew by hand, check the clock | 5-45 minutes |
| ERR_CERT_COMMON_NAME_INVALID | Certificate domain does not match the address | Reissue covering both names | 15-60 minutes |
| ERR_CERT_AUTHORITY_INVALID | Missing intermediate, or self-signed | Install the full chain | 20-60 minutes |
| ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Protocols too old or too restricted | Enable TLS 1.2 and 1.3, drop legacy ciphers | 30-90 minutes |
| ERR_CERT_REVOKED | The authority revoked the certificate | Check for key compromise, reissue | 2-8 hours |
Three layers of monitoring
To stop a certificate dying quietly, get the same information from three independent places.
| Layer | What it watches | Frequency | Alert threshold | Who receives it |
|---|---|---|---|---|
| External check | Expiry date and chain | Daily | 30, 14, 7 and 2 days out | Email plus team channel |
| Availability | Status of home, category, cart, checkout | Every 5 minutes | Two failures in a row | SMS plus call |
| On-server | Whether the renewal task ran | Every run | Any error output | Technical owner |
| Real browser | Chain errors on mobile | Weekly, manual | A single failure | Checklist |
Make sure the alert email does not go to the account of someone who has left the company — one of the most common root causes we see. Route alerts to a team channel and at least two people. For the same discipline on the order, stock and integration side, see our piece on APIs and e-commerce integrations; a silent failure is always the expensive one.
What you should have at hand for diagnosis
- openssl s_client: shows the full chain the server sends plus the expiry date, without papering over gaps the way a browser does.
- An external chain test: checks from an independent server, removing illusions created by caching on your own network.
- A real device on mobile data: open the site with Wi-Fi off, inside an in-app browser. A missing intermediate shows up here most clearly.
- Certificate Transparency logs: public records of who issued certificates for your domain, and the only way to catch an unauthorised one.
A Solid HTTPS Setup in 30 Days
Days 1-7: inventory and current state
Write every domain and subdomain you own into one table: main site, www, blog, panel, api, live and retired campaign addresses. For each, note the certificate's expiry date, type and owner. Then crawl the site and list every resource still requested over HTTP. Change nothing this week; just see what is there. Most teams find two or three forgotten subdomains.
Days 8-14: installation and mixed-content cleanup
Install certificates wherever they are missing. Bulk-update http:// links in the database and fix theme and third-party code. Make the HTTP to HTTPS 301 a single hop — http://site should reach https://www.site in one jump, not two. Then walk the home page, three categories, three products, cart, checkout and the distance sales agreement page with the console open, until no warning remains.
Days 15-21: automation and hardening
Automate renewal, force one run and confirm it genuinely renewed. Make sure the web server reloads afterwards. Disable TLS 1.0 and 1.1, leave 1.2 and 1.3 enabled. Start HSTS at 300 seconds. Synchronise the server clock over NTP — a real share of ERR_CERT_DATE_INVALID errors come from a drifted clock, not an expired certificate.
Days 22-30: monitoring, a drill, and documentation
Set up the three monitoring layers and test that alerts arrive: break the certificate on a test domain and measure how many minutes pass before the alert lands. Raise HSTS max-age to one year. Then write a one-page note: domains, certificate types, renewal method, where alerts go, who to call, five lines of response steps. Keep it where at least two people can reach it.
Here is the job for tomorrow morning: open your own site, click the padlock, note the certificate's expiry date, then open the same page on your phone over mobile data. If fewer than 30 days remain, or mobile shows a warning desktop did not, you have work to do today. If you are considering a setup where certificate management runs automatically on the platform side, the Tecof e-commerce infrastructure page shows how that part works; but whatever platform you run, that two-minute check stays your responsibility.
Frequently Asked Questions
Is a free SSL certificate safe?
Yes. The encryption a Let's Encrypt certificate provides is identical to that of an 8,000 TL one; both use the same protocol and key lengths. What differs is how much the authority investigated you, the support and the warranty. Banks and payment institutions accept it. Its only real difference: 90-day validity makes automatic renewal mandatory.
Will an SSL certificate slow my site down?
Not measurably. With TLS 1.3 the handshake completes in one round trip, and the encryption cost on modern processors is negligible. HTTP/2 and HTTP/3 run only over HTTPS, so the move usually makes a site faster. If you see slowness, the cause is redirect chains, unoptimised images or server response time — not the certificate.
My certificate expired — how fast can I be back up?
If automatic renewal is configured and only the task stalled, triggering it by hand and reloading the web server takes 5-15 minutes. Issuing from scratch, budget 20-45 minutes for DV. Do not take the site offline meanwhile; a closed site avoids the error message but creates a separate search problem. Fix the certificate directly.
Do I need HTTPS on every page, or is checkout enough?
Every page. Encrypting only the checkout was a 2010s approach: the session cookie travels in the clear on HTTP pages, the browser shows "Not secure" elsewhere, and mixed-content problems appear. Google also struggles with mixed structures during indexing. Site-wide HTTPS is the only correct setup.
Wildcard certificate, or a separate one per subdomain?
Above three subdomains a wildcard makes management easier. Still, keeping payment, admin panel and API outside it with their own certificates is safer, since a leaked wildcard key puts every subdomain at risk at once. In small setups, one free certificate per subdomain is fine.
Should I enable HSTS right away?
Not immediately — gradually. First confirm the whole site and all subdomains run cleanly over HTTPS. Start max-age at 300 seconds, raise it to a day after a clean week, then to a year. Leave includeSubDomains and preload until last: getting off the preload list can take months, during which you cannot fall back to HTTP.
What happens to my certificate if I migrate the domain?
A certificate is bound to the domain, not the server, so if the domain stays the same you can copy it across or issue a fresh one there. Have it ready on the new server before changing DNS; otherwise some visitors land on a certificate-less server during propagation and see an error screen. Lowering the TTL to 300 seconds 24 hours before the move shortens the transition.
Besides SSL, what is checked in a virtual POS application?
Alongside valid HTTPS, banks want your distance sales agreement, pre-information form, return and delivery terms, privacy policy and contact pages reachable. They also check that prices are VAT-inclusive, that ETBIS registration is complete, and that the registered company name appears on the site. If those pages open over HTTP or show mixed-content warnings, the application can be delayed.
Is SSL mandatory under KVKK?
No clause in the KVKK text says "install SSL"; the law requires the data controller to take appropriate technical and administrative measures. The authority's guidance on technical measures, however, explicitly includes encrypting data in transit. Since names, addresses, phone numbers and order histories are personal data, HTTPS is the expected minimum for any store handling registrations and orders. Unencrypted transmission is read against you in a breach.
My certificate is valid but the browser still shows no padlock — why?
Almost always mixed content. Some image, font, script or iframe is loading from an HTTP address. Open the console and look for "mixed content" warnings; the source is usually old image URLs in the database, hard-coded links in a theme, or a legacy chat or ad snippet. Convert them to HTTPS and the padlock returns.