SSL certificates: what an online store owner should know

HTTPS for an online store: what needs to be protected

An online store must run over HTTPS on all pages: from the catalog to checkout. This requires a valid TLS certificate, proper web server configuration, and automatic renewal. The certificate protects data during transmission but does not eliminate site vulnerabilities, does not confirm the seller's integrity, and does not protect the server from malware.

Short algorithm for the ownerAppoint a person responsible for the domain, hosting, and certificate. Enable HTTPS for the entire site, automatic renewal, and error notifications. Leave the TLS 1.3 and TLS 1.2 protocols. Protect registrar, hosting, CDN, and CMS accounts with multi-factor authentication. Transfer the input of card details to a certified payment provider. Verify the configuration after every site change.

What SSL, TLS, and HTTPS mean

TLS — a protocol that creates a secure connection between the buyer's browser and the site's server. It ensures the confidentiality of transmitted data, protects it from undetected tampering in transit, and allows the browser to verify for which domain the certificate was issued. TLS is exactly what is used in HTTPS. The name "SSL certificate" remains in everyday use, although the SSL 2.0 and SSL 3.0 protocols are obsolete and should not be used. This is explained in the current OWASP TLS cheat sheet.

When opening an https:// address, the server sends the browser a certificate with a public key, domain names, expiration date, and certificate authority data. The browser checks the chain of trust, domain match, expiration date, and certificate status. After this, the parties agree on session keys and encrypt the exchange.

What HTTPS protects

logins, passwords, contact details, and order content during transmission;
session cookies, if the site correctly sets the Secure, HttpOnly, and SameSite attributes for them;
against undetected substitution of a page or server response in an unsecured network;
the browser's connection with the domain specified in the certificate.

What HTTPS does not protect

Risk	Why a certificate is not enough	What else is needed
Phishing store	An attacker can get a valid certificate for a similar domain.	Verification of the exact address, brand protection, monitoring of fake domains, and notifying customers.
Site or CMS hack	HTTPS will just as securely deliver malicious code added to a hacked site to the buyer.	Updating the platform and modules, change control, least privileges, logging, and backups.
Administrator password theft	TLS protects password transmission, but does not help if the password was phished, reused, or stolen from a device.	Unique passwords, password manager, multi-factor authentication, and separate accounts.
Malicious code on a buyer's or employee's device	Data can be stolen before encryption or after decryption.	System updates, endpoint protection, and restriction of user rights.
Payment page compromise	A third-party script can read data directly in the browser.	Control of payment scripts, content security policy, change detection, and correct integration with the acquirer.

Chrome abandoned the padlock as a universal symbol of trust because HTTPS indicates a secure channel, not the reliability of the page owner. The Chromium team's material notes that almost all phishing sites also use HTTPS; since Chrome 117, the padlock was replaced by a neutral settings icon. Therefore, employees and buyers need to check the exact domain name, rather than look for a "green padlock". Source: An Update on the Lock Icon.

Why this is important for a Ukrainian online store

An online store processes names, phone numbers, delivery addresses, order histories, and other information that may be personal data. Article 24 of the Law of Ukraine "On Personal Data Protection" obliges owners and administrators to protect such data from accidental loss, unlawful processing, destruction, and access. The law defines the obligation of protection but does not establish a separate requirement for every store to buy a paid OV or EV certificate. Source: Law of Ukraine "On Personal Data Protection".

The Ukrainian context requires special attention to phishing. In March 2026, CERT-UA recorded the mailing of letters allegedly on behalf of CERT-UA itself with a call to download a file, and the State Service of Special Communications and Information Protection (SSSCIP) in June 2026 reported numerous campaigns using compromised accounts and social engineering techniques. These are confirmed attacks on Ukrainian organizations, not reports of an attack on a specific store or program. Sources: CERT-UA report on UAC-0255 and SSSCIP review on phishing campaigns.

HTTPS is not a seller's IDA valid certificate for a domain means that the connection with this domain is secure and the certificate authority has verified the data according to the validation type. It does not confirm the quality of the goods, order fulfillment, the financial state of the company, or the absence of malicious code.

Which certificate to choose

Owner verification level

Type	What the certificate authority checks	When appropriate
DV Domain Validation	Control over the domain. Data about the legal entity is not checked.	Most online stores, sites, and internal subdomains, especially when issuance and renewal are automated.
OV Organization Validation	Control over the domain and the existence of the organization according to the certificate authority's rules.	When a business process, contract, or internal policy requires verified information about the legal entity in the certificate.
EV Extended Validation	Extended verification of the legal entity according to separate rules.	When explicitly required by the policy of the organization or partner. EV does not create stronger encryption and does not give a modern store a "green address bar".

DV, OV, and EV can use the same modern encryption algorithms. The difference lies in the applicant verification procedure and the certificate details. A free DV certificate from a universally recognized certificate authority does not encrypt weaker due to the lack of price. Let’s Encrypt issues free DV certificates, but does not issue OV and EV; the private key is created and stored on the site owner's side. Source: official Let’s Encrypt FAQ.

Number of domains

Single-name certificate covers a specific domain name specified in the SAN field.
Multi-domain certificate contains multiple names in the SAN field. The names SAN and UCC often describe the same mechanism, not a different level of protection.
Wildcard certificate covers first-level subdomains, such as *.example.ua, but usually does not cover example.ua itself without a separate record. One stolen private key of such a certificate creates a risk for all covered subdomains. OWASP advises using a wildcard only when justified and not sharing it between systems with different trust levels.

Validity period and automatic renewal

The validity periods of public TLS certificates are shortening. Under the current baseline requirements of the CA/Browser Forum, certificates issued between March 15, 2026, and March 15, 2027, cannot be valid for longer than 200 days. From March 15, 2027, the limit will be 100 days, and from March 15, 2029 — 47 days. Source: CA/Browser Forum TLS Baseline Requirements 2.2.2.

Issuance Date	Maximum Validity	Practical Conclusion
15.03.2026–14.03.2027	200 days	Manual renewal already poses a significant risk of downtime.
15.03.2027–14.03.2029	100 days	Automatic issuance, installation, and verification are required.
From 15.03.2029	47 days	Certificate management must be fully automated.

As of July 2026, standard Let’s Encrypt certificates are valid for 90 days, and a separate profile allows the use of shorter certificates. The owner must control not the calendar purchase date, but the operation of the automatic ACME client, the successful installation of the new certificate, and the restart or reloading of the web server configuration.

Main attack and failure scenarios

Scenario	What the employee or buyer sees	Consequence	First action and responsible party
HTTP interception or downgrade from HTTPS to HTTP	The address starts with `http://`, the browser shows an unsecured connection, or part of the page loads without protection.	Interception or alteration of login, cookie, contact details, and order in transit.	The administrator switches the entire site to HTTPS, sets up a permanent redirect, and after checking, enables HSTS.
Phishing site with a similar domain and a valid DV certificate	The page looks like the store, HTTPS works, but the domain differs by a character, word, or domain zone.	Theft of passwords, payment data, or funds.	The employee records the URL and screenshots; the owner notifies the registrar, hosting, payment partner, and Cyberpolice.
Expired certificate, incorrect domain name, or incomplete chain	The browser blocks the page with a privacy or invalid certificate warning.	Buyers cannot open the site or complete payment.	The administrator advises not to bypass the warning, checks the issuance, SAN, full chain, and certificate deployment.
Private key theft	There may be no visible signs.	The attacker can use the key to impersonate the server in scenarios where they control the route, DNS, or infrastructure.	The administrator revokes the certificate, creates a new key pair on a clean system, and investigates the method of compromise.
Domain, DNS, CDN, or hosting hack	The site may look normal or lead to another server; a valid certificate will sometimes also be present.	Spoofing the site, mail, payment details, and intercepting orders.	The owner blocks the compromised account, involves the registrar and hosting; the administrator restores verified DNS records and changes access keys.
Hacked module or third-party JavaScript	The site opens over HTTPS without warnings; the buyer may see an extra field, a different payment form, or nothing suspicious.	Web skimming: stealing data from a form in the browser before sending it to the payment provider.	The administrator disables the compromised component, saves evidence, checks for changes; the owner notifies the acquirer and executes the response plan.

How to correctly configure HTTPS

Compile a list of names. Add the main domain, the www variant, payment, and internal subdomains if they are actually used. Do not buy a wildcard just for convenience.
Issue the certificate on the server or through a managed platform. The private key should not be sent in messengers, by mail, or stored in a shared folder.
Automate the full cycle. The ACME client must get a new certificate, install it, reload the server configuration, and report an error. A separate external monitoring should check the actual certificate seen by the buyer.
Leave modern protocols. OWASP recommends using TLS 1.3 by default and supporting TLS 1.2 for compatibility. TLS 1.0, TLS 1.1, SSL 2.0, and SSL 3.0 must be disabled. As of July 2026, SP 800-52 Rev. 2 remains the current published NIST guideline; NIST has already started its revision in 2026.
Redirect HTTP to HTTPS. Use a permanent server redirect 301 or 308. Specify HTTPS addresses in canonical, the sitemap, and hreflang. Google prefers correct HTTPS pages as canonical, but HTTPS itself does not guarantee search rankings. Source: Google recommendations on canonical URLs.
Remove mixed content. Images, fonts, styles, scripts, forms, and API requests must load over HTTPS. Active HTTP content can be blocked by the browser, and its substitution allows executing third-party code.
Enable HSTS after verification. The Strict-Transport-Security header instructs the browser to use HTTPS from then on. First, check all subdomains and start with a small max-age; an erroneous HSTS configuration can make the site inaccessible. Guidelines for redirects, HSTS, and secure cookies are provided in the web.dev guide to enabling HTTPS.
Protect control panels. For the registrar, DNS, CDN, hosting, CMS, and mail, use separate accounts, multi-factor authentication, and minimum necessary rights. Remove access for dismissed employees and former contractors.
Control certificate issuance. Certificate Transparency logs allow you to see certificates issued for your domains and detect unexpected issuance. How monitors work is described on Certificate Transparency.

HTTPS and accepting payments

If the store redirects the buyer to the page of a bank, acquirer, or other payment provider, the store's TLS connection protects the path only up to the point of transition. The payment page must have its own valid certificate, and the address must be verified against the provider's documentation. The store should not independently add fields for the card, store CVV, or transmit details through its own database unless such an architecture is agreed with the acquirer and complies with applicable PCI DSS requirements.

The National Bank of Ukraine specifically warns about fraud during online payments and fake online stores. For the buyer, this means that the presence of HTTPS must be evaluated together with the exact site address, payment method, and seller verification. Practical materials are collected on the official NBU resource "FraudGoodbye".

The current version of the standard is PCI DSS 4.0.1. The payment page security requirements that came into effect on March 31, 2025, focus on authorizing scripts, verifying their integrity, and detecting unauthorized changes. They counter web skimming, where code in the browser copies details from a form. Source: PCI SSC: Payment Page Security and Preventing E-Skimming.

Redirects and embedded forms carry different risksFor a store that completely redirects the buyer to the payment provider's site, the scope of controls is usually smaller than for a page with an embedded payment form. The final PCI DSS scope and compliance validation form are determined together with the acquirer or payment brand. Clarifications on the SAQ A criteria were published by the PCI Security Standards Council.

What to do if the browser shows a certificate error

Do not ask buyers to bypass the warning. Temporarily suspend ad traffic and payments if the secure checkout path is unavailable.
Record the error. Save the exact time, domain, error text, screenshot, external monitoring data, and recent changes on the hosting.
Check the cause. Common options: expired; certificate issued for the wrong name; server returning an old certificate; missing intermediate certificate; incorrect time on the server; CDN and main server have different configurations; automatic renewal executed, but the web server did not reload the new file.
Fix the configuration. Reissue the certificate if necessary, install the full chain, and test every public domain from different networks.
Test the checkout process. Go through the catalog, authorization, cart, redirect to the payment provider, return after payment, notifications, and integration requests.
Find the organizational root cause. Fix the automation, add an external alert, document the process owner and a backup contact.

What to do if a key or web server is compromised

Restrict access to the affected node. Do not delete files and logs, and do not reinstall the system until evidence is secured, unless it is necessary to stop ongoing harm.
Preserve evidence. Take a snapshot of the system or disk, export web server, CDN, CMS, DNS, hosting panel, and authentication logs. Record the time in a single time zone.
Revoke the certificate. Create a new private key on a verified system and obtain a new certificate. Simple renewal with the old key does not resolve the compromise.
Change related secrets. Change administrator passwords and sessions, API keys, database access, SSH, hosting panels, CDN, registrar, DNS, mail, and repository. Start from a clean device.
Inspect the site. Look for new administrators, changed files, third-party scripts, task schedulers, web shells, redirection rules, altered payment details, and unexpected certificates in CT logs.
Restore only from a verified backup. The backup must have been created before the breach and tested in a separate environment. After restoring, install updates, eliminate the root cause, and only then return the site to operation.
Notify affected parties. Involve the hosting, developer, acquirer, data protection officer, and lawyer. A cyber incident can be reported to CERT-UA; signs of a criminal offense or fraud — via the Cyberpolice electronic appeal system.

What you must not doDo not ignore the browser warning. Do not send the private key in a chat. Do not issue a new certificate with a compromised key. Do not clear logs prior to investigation. Do not restore the site over the compromised system. Do not connect a backup to an unverified server.

Backups and recovery

A certificate is not a backup copy of a site. Recovery requires verified copies of the code, database, uploaded files, web server configuration, DNS records, CDN rules, integration settings, and a documented certificate issuance process. A private key should not be unnecessarily duplicated: in many configurations, it is safer to create a new key and reissue the certificate.

Store at least one copy separate from the production server and its always-accessible accounts. Regularly check the integrity of backups and perform test recoveries in an isolated environment. CISA recommends maintaining offline encrypted copies of critical data and regularly testing their availability and integrity in a disaster recovery scenario. Source: CISA StopRansomware Guide.

HTTPS, Torgsoft, and the store's Windows server

An online store's TLS certificate protects web connections to the corresponding domain. It does not protect the local server or the main computer running Torgsoft, cash register computers, network folders, and backups. These systems require separate protection.

the server or main computer with Torgsoft should ideally be used only for running the program and database;
it should not be used to read mail, open messengers, download random files, browse third-party sites, and install unnecessary programs;
direct RDP access from the public internet must not be opened;
remote access must be granted in a controlled manner: via VPN or another secure gateway, using separate accounts, with logging and multi-factor authentication if supported by the chosen solution;
employees must work without permanent administrator rights;
a backup on the same server or a permanently connected drive can be corrupted or encrypted along with the primary data;
recovery requires a healthy backup created before the breach and verified by a test deployment.

Limits of Torgsoft assistance

Torgsoft technical support can help install the program and deploy a viable database. It is not a file decryption service and cannot restore commercial information if there is no healthy backup. The online store's web certificate, Windows server protection, and backups must be treated as separate processes with designated responsible parties.

Who is responsible for what

Role	Responsibilities	What the owner checks
Business Owner	Appoints responsible persons, approves the payment scheme, recovery time, budget, and response procedure.	There is a list of assets, contractor contacts, backup access, and a report on the latest audit.
System Administrator or Hosting	Configures TLS, auto-renewal, HSTS, monitoring, logs, backups, and recovery.	The certificate is renewed without manual action; alerts are sent to at least two people.
Site Developer	Removes mixed content, secures cookies, minimizes scripts, updates the platform, and controls payment page changes.	There is a list of modules and scripts, change history, and a vulnerability remediation plan.
Payment Provider and Acquirer	Provides documented integration, PCI DSS requirements, payment page URLs, and response procedures.	Integration follows current documentation; the store does not collect unnecessary card details.
Store Employee	Does not bypass browser warnings, checks the domain, does not share keys and passwords, immediately reports suspicious changes.	The employee knows who and via which channel to report an incident to.
External Contractor	Works via a personal account, at agreed times and within issued permissions; access is revoked upon completion.	There are no shared or perpetual contractor accounts.

Practical Checklist

all pages, forms, images, scripts, and APIs work over HTTPS;
HTTP permanently redirects to HTTPS without intermediate fallbacks;
the certificate covers all required domain names and is served with the full chain;
TLS 1.3 and TLS 1.2 are enabled; older SSL/TLS versions are disabled;
automatic renewal completes successfully, including applying the new certificate;
external monitoring checks validity, HTTPS availability, and certificate changes;
HSTS is enabled after checking all subdomains;
accounts for registrar, DNS, CDN, hosting, mail, and CMS are protected with multi-factor authentication;
access for former employees and contractors has been removed;
there is a list of third-party scripts, and payment pages are monitored for unauthorized changes;
the store does not store card details outside the architecture agreed with the acquirer;
backups are separated from the production server and verified by test recovery;
primary and backup responsible persons are assigned for the domain, hosting, certificate, and response;
TLS is re-checked after every change of hosting, CDN, DNS, payment integration, or web server.

For external configuration testing, you can use the Qualys SSL Labs Server Test. OWASP also recommends verifying the configuration after hardening settings and provides a list of online and local tools in the TLS Cheat Sheet. An automated test does not replace testing the cart, authorization, payment redirect, API, and restoration from a backup.

Last name and first name
Phone number
Other contact information
Database type
Do you need a call and consultation from a company employee? Yes No Choose one of the options
I agree with Torgsoft's Privacy Policy. Please review Torgsoft's Privacy Policy. If you agree, please confirm below.

HTTPS for E-commerce: TLS Certificate Setup and Security