Why Choose an SSL Certificate for Your Business Website?

Why HTTPS Matters for Every Website

An SSL/TLS certificate is the foundation of HTTPS, the encrypted protocol that protects data traveling between a visitor’s browser and your web server. Without SSL, data moves over the internet in less secure ways. With it, passwords, credit card numbers, form submissions, and login sessions are encrypted, making them far harder for attackers to intercept.

The Business Case Against HTTP

Browsers have signaled the danger of unencrypted sites for years. Starting in 2017, Chrome began flagging all HTTP pages collecting passwords or credit cards as “Not Secure”, a full-page warning that most visitors read as a reason to leave. That warning has only expanded since then. Today, HTTPS is the default expectation for every modern website. When visitors see the padlock icon and the green “Secure” label, trust increases immediately. When they see a warning, trust collapses.

The numbers make the business case clear. According to GlobalSign research, 84% of shoppers abandon a purchase if data is sent over an unsecured connection. For e-commerce sites, that’s significant revenue lost to a single missing certificate. For SaaS platforms and service businesses, it’s credibility lost before a prospect even reads your pitch. Google rewards HTTPS sites with better search rankings, as much as a 5% visibility boost compared to HTTP-only sites, making SSL a dual conversion and SEO lever that affects both visitor behavior and search visibility.

What an SSL Certificate Actually Does

An SSL certificate does two distinct things. First, it encrypts data in transit using the Public Key Infrastructure (PKI), a cryptographic framework built on asymmetric encryption. A public key encrypts information, and only the corresponding private key can decrypt it, a mathematical guarantee that data remains unreadable if intercepted during transmission.

Second, it verifies your site’s identity. A Certificate Authority (CA), an organization trusted by every major browser, checks your domain ownership or organizational legitimacy before issuing the certificate. That verification turns the “Secure” label from a technical feature into a genuine trust signal that influences visitor behavior.

How SSL Protects Your Data and Builds Trust

When a visitor arrives at an HTTPS site, their browser and your server negotiate an encrypted tunnel during the TLS handshake. Everything flowing through that tunnel- form data, session cookies, payment details, authentication tokens- is scrambled in a way only your server can unscramble. Without SSL, this data travels in plaintext and is vulnerable to eavesdropping, man-in-the-middle attacks, and credential theft. With SSL, the connection is authenticated and encrypted, protecting both the confidentiality and integrity of data in transit.

Encryption Strength and Cipher Suites

Encryption strength depends on the TLS version your certificate uses and the cipher suites your server supports. Modern certificates rely on TLS 1.2 or TLS 1.3, paired with strong cryptographic algorithms such as AES-GCM and ChaCha20-Poly1305. Older protocols like SSL 3.0, TLS 1.0, and TLS 1.1 contain known vulnerabilities and are no longer acceptable for compliance-sensitive workloads or public-facing services. Attackers have exploited these outdated protocols, and modern compliance standards explicitly forbid them.

The CA/Browser Forum, an industry group of major CAs and browser vendors, published the Baseline Requirements, which establish minimum standards for how CAs must operate, what certificate content must include, and how identity must be verified. These requirements ensure that every certificate issued by any trusted CA meets the same rigorous security bar. That consistency is why you can buy a certificate from any authorized reseller and have it recognized by any browser worldwide, whether your visitors are in North America, Europe, Asia, or anywhere else.

Why the Padlock Matters to Your Visitors

Niya Digital’s team has observed that visitors often make trust decisions in milliseconds: they see the padlock and green “Secure” label, or they don’t. A browser warning about a missing or misconfigured certificate is noticed immediately and can kill conversions. The visual confidence cue, knowing their data is encrypted, reduces friction and increases the likelihood of form submission, account creation, or purchase completion. Conversely, the absence of these trust signals, or a red warning icon, makes visitors question your legitimacy and often leads them to abandon their intended action.

Understanding Certificate Validation Levels

Not all SSL certificates are created equal. The validation level a Certificate Authority performs before issuing a certificate determines how much identity assurance the certificate provides. The CA/Browser Forum defines three primary validation levels, each suited to different business needs, use cases, and visitor trust requirements.

Domain Validation (DV) Certificates

Domain Validation certificates require you to prove ownership of your domain only. The Certificate Authority sends you a verification link via email, asks you to add a specific DNS record to your domain’s DNS settings, or requests that you upload a verification file to your web server’s root directory. The process is fully automated and completes in minutes to hours, often within the same day. Once issued, the certificate encrypts data in transit just as securely as higher-tier validation options. However, the certificate displays no organizational identity; a visitor sees the padlock but learns nothing about who operates the site or whether it’s a legitimate business entity.

DV certificates work best for personal blogs, test environments, internal projects, development servers, and any site where organizational identity isn’t a trust factor for visitors. They’re also the most affordable option available and the fastest to obtain, making them popular with startups and individuals. For a small business or startup prioritizing speed-to-market over organizational credibility signals, DV is often the right starting point. Encryption is the same as with higher validation levels, but trust signaling is minimal.

Organization and Extended Validation Certificates

Organization Validation (OV) certificates go further than DV. Beyond verifying domain ownership, the Certificate Authority checks that your organization is a legally registered business by reviewing government records, business directories, or requesting official documentation. The validation process typically takes hours to a few business days, depending on how quickly you can provide documentation. Once issued, your organization’s legal name appears in the certificate details, which visitors can see by clicking the padlock icon. This organizational verification provides considerably more trust than DV, especially for visitors making high-value decisions.

Extended Validation (EV) certificates represent the highest level of assurance available. The Certificate Authority conducts a rigorous validation process that includes verifying legal registration, confirming business phone numbers and addresses through independent sources, validating business ownership through corporate registries, and sometimes conducting personal interviews or additional verification calls. The process can take several days or even weeks, but it delivers the most comprehensive identity verification in the PKI ecosystem. EV certificates are worth the investment for e-commerce sites processing payment cards, financial services platforms, large retail operations, government agencies, and any business where visitor trust and organizational credibility are directly tied to revenue or sensitive functions.

Choosing the Right Certificate Type for Your Site

Beyond validation level, certificates come in different types based on how many domains and subdomains they protect. Choosing the right type prevents you from juggling multiple certificates and significantly simplifies renewal management across your infrastructure. The wrong choice can cause SSL errors on parts of your site or add unnecessary management complexity.

Single-Domain and Wildcard Certificates

A single-domain SSL certificate protects one domain only, for example, www.example.com. If your traffic also goes to the bare domain (example.com without the www prefix), you must either purchase a certificate covering both domains or set up an automatic redirect from one to the other. For most websites, a single-domain certificate is sufficient and the most cost-effective option. The certificate is simple to manage, renewal is straightforward, and you don’t pay for coverage you don’t need.

A Wildcard SSL certificate covers one base domain and all of its first-level subdomains at once. A wildcard certificate for *.example.com protects mail.example.com, api.example.com, blog.example.com, staging.example.com, and any other subdomain you create or add in the future, all under a single certificate. You can add unlimited new subdomains without buying additional certificates or repeating the validation process. This cost-effectiveness and simplicity make wildcards attractive for growing organizations. Still, there’s a security tradeoff: one private key secures all subdomains, so if that key is compromised, every subdomain is exposed. Additionally, a wildcard doesn’t cover the bare domain (example.com), so you may still need a second certificate if you route traffic to the bare domain.

Multi-Domain (SAN) Certificates

A SAN (Subject Alternative Name) certificate can secure up to 250 distinct domain names and subdomains within a single certificate. This is ideal if you manage multiple unrelated brands, maintain regional domain variants for different markets, operate a portfolio of product domains, or run a mix of corporate and product-specific websites. Each domain included in the certificate is explicitly listed in the certificate’s Subject Alternative Names section and is not covered by a wildcard pattern. This provides precise coverage; you protect exactly the domains you choose, no more and no fewer.

SAN certificates cost more than single-domain certificates, and pricing typically scales with the number of domains you include. Renewal is simpler than managing dozens of individual certificates, but you must renew every domain in the certificate together on the same schedule. For large organizations managing many distinct domains or multiple brands, a SAN certificate balances security, simplicity, and operational cost. It avoids the certificate sprawl of managing individual certificates per domain while staying flexible about which domains it covers.

Security, Compliance, and Business Requirements

Many businesses assume SSL is optional until a compliance audit arrives. In reality, SSL has moved from best practice to requirement for any site handling sensitive data, payment information, or customer personal information. Understanding which standards apply to your business helps prevent security gaps, avoid costly retrofitting, and stay compliant with laws and industry standards.

PCI DSS and Payment Card Processing

If your website accepts credit card payments, even through a third-party payment processor or gateway, you’re subject to the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS v4.0 became mandatory in March 2025 and explicitly requires a certificate inventory and TLS configuration management as part of requirement compliance. More specifically, Requirement 4.2.1 mandates that all communications with cardholder data use strong cryptography, which in practice means TLS 1.2 or higher.

Old TLS versions like TLS 1.0 and 1.1 contain known vulnerabilities and are no longer acceptable under PCI DSS. If you’re still using these protocols, you’re out of compliance and at immediate risk of payment processor penalties, higher processing fees, or outright suspension of payment processing. Upgrading to a modern SSL certificate that supports TLS 1.2 or 1.3 is the primary technical fix. Many payment processors already enforce these requirements, so waiting isn’t a safe option if you process credit cards.

Compliance Frameworks and Business Trust Signals

GDPR, HIPAA, and various industry-specific regulations don’t explicitly mandate SSL certificates but expect strong encryption as a foundational part of your data protection controls. Data-security regulations vary significantly by jurisdiction, industry, and the type of data you handle; confirm with legal counsel or a compliance professional which standards apply to your specific business and customer data. Beyond formal compliance, SSL signals your commitment to security. Your visitors assume you’re secure. Conversely, the absence of SSL tells visitors you don’t care about their safety. That perception costs conversions, referrals, and long-term reputation damage.

Installation and Configuration Best Practices

Purchasing a certificate is only half the work. Installation matters equally. A poorly installed certificate can trigger browser warnings, reduce trust signals, create SSL errors on certain domains, or fail to protect all your website’s traffic. Understanding the installation process and common pitfalls prevents these problems and ensures your certificate works correctly immediately upon activation.

Common Installation Approaches

Installation methods vary significantly by hosting environment. On shared hosting with cPanel, you typically upload your certificate files and private key through a web-based control panel interface, and the hosting provider automatically configures the server. On a VPS or dedicated server, you may need to manually place the certificate files in the correct server directory, configure your web server (Nginx, Apache, or IIS) to use them, and test the configuration. On cloud platforms like AWS or Google Cloud, certificate management is often integrated into load balancing services or CDN configuration.

Regardless of your platform, the core steps remain consistent: generate a Certificate Signing Request (CSR) on your server containing information about your domain and organization; submit that CSR to the Certificate Authority; receive the issued certificate and intermediate chain; and install all three components (private key, certificate, intermediate chain) in the correct locations on your server. Mistakes at this stage- missing the intermediate certificate, installing the certificate on the wrong domain, configuring your server incorrectly, or using the wrong port- are common sources of browser warnings and failed validation.

Testing and Validation

After installation, test your configuration using an online SSL checker, your browser’s developer tools, or a command-line utility. Verify that the certificate covers all domains and subdomains your site uses (including both www and non-www versions, plus any subdomains), that the complete certificate chain is present and in the correct order, and that TLS 1.2 or higher is enabled.

A misconfigured certificate that covers example.com but not www.example.com will generate a warning for visitors arriving via either URL. These mistakes are easy to prevent with a quick validation check after installation, and they’re usually simple to fix once you identify them.

Managing Certificate Renewals and Avoiding Expiration

An SSL certificate has a validity period, typically 1 or 2 years from issuance. When that period ends, the certificate expires. An expired certificate doesn’t slow your site down; it stops it completely. Every visitor sees a full-page browser warning, “This site’s certificate has expired,” or similar language, and many modern browsers block the page from loading entirely. An expired certificate is a hard outage that immediately affects revenue, user experience, and brand reputation.

Renewal Notifications and Timeline

Most CAs send renewal notifications via email, typically beginning 60 days before expiration and repeating every 30 days, then 10 days before expiration, and on the day of expiration itself. You’ll also receive notifications from your reseller; providers like Niya Digital send renewal reminders 30 days before expiration. Despite multiple reminders, certificate expiration remains a common cause of website outages because renewal notifications sometimes land in spam folders, get lost in busy inboxes, or are overlooked during hectic business periods.

Manual renewal is only available within 30 calendar days before a certificate expires. If you wait until the last week, you risk not giving the CA enough time to validate your request and issue your new certificate before your site goes offline. Best practice is to renew 30 days before expiration, giving the CA ample time to validate your request through email, DNS, or file verification, issue the new certificate, and allow you to install it before the current certificate lapses. This provides a comfortable safety margin and reduces stress.

Auto-Renewal as a Safety Net

Many certificate providers and resellers offer automatic renewal as a standard feature or optional add-on. Your certificate renews automatically 30 days before expiration, and a new certificate installs without manual intervention. Auto-renewal eliminates the risk of human oversight causing costly downtime.

However, auto-renewal isn’t bulletproof; renewal requests can fail silently because of validation issues, DNS changes, server misconfigurations, or email delivery problems. Even with auto-renewal enabled, monitoring certificate expiration dates and receiving renewal notifications remain prudent safety practices for critical websites.

Fixing Mixed Content and Browser Security Warnings

After installing a fresh SSL certificate, you may still see browser warnings, a broken padlock icon, or messages about insecure content. The culprit is usually mixed content: HTTPS pages that load resources over unencrypted HTTP. Understanding and eliminating mixed content is essential for presenting a clean, trustworthy site to visitors.

What Mixed Content Is and Why It Matters

Mixed content occurs when a secure HTTPS page requests resources, images, stylesheets, JavaScript files, or embedded content over unencrypted HTTP connections. The main page is served securely over HTTPS, but one or more sub-resources are not. Browsers detect this and display a warning, block the content entirely, or show a broken padlock icon instead of the green security indicator. Modern browsers are increasingly strict about mixed content because it defeats the purpose of HTTPS. If an attacker can intercept and modify a JavaScript file, they can inject malware or steal data even if the main connection is encrypted.

Mixed content presents two primary risks. First, any HTTP resource can be intercepted and altered by an attacker positioned on the network path, potentially introducing malware into your page or stealing sensitive data. Second, the browser warning or broken padlock immediately signals insecurity to visitors, which can dramatically damage trust and conversions. A fully secure HTTPS connection is only as secure as its least-secure resource, so even one unencrypted asset can compromise the entire security posture.

Finding and Fixing Mixed Content

Most mixed content results from hardcoded HTTP links in your HTML, CSS, or JavaScript, often in image URLs, script includes, stylesheet references, or API calls. If you recently migrated your site from HTTP to HTTPS, old content may still reference HTTP URLs that were never updated. Search your HTML source code, theme files, and plugin code for “http://” links to resources hosted on your own domain, and replace them with “https://” or protocol-relative links like “//example.com/resource”. Protocol-relative URLs automatically use the same protocol (HTTPS or HTTP) as the page itself, providing a simple fix.

For resources hosted on external services or CDNs, verify that those services support HTTPS connections. Suppose they don’t; consider downloading and hosting the resource yourself on your HTTPS-enabled server. Testing is simple: load your site in Chrome or Firefox, press F12 to open the browser developer tools, click the Console tab, and look for warnings about blocked or mixed content. Those warnings pinpoint exactly which resources need fixing. Address each warning by updating its URL to HTTPS or removing the resource if it’s no longer needed.

Building Visitor Trust Through SSL and HTTPS

SSL does more than encrypt data; it fundamentally changes how visitors perceive your site and make trust decisions. The visual signals (padlock, “Secure” label, no warnings) are trust cues that influence conversions, referrals, brand perception, and long-term customer relationships. Making SSL work for your business means understanding its full impact on visitor behavior and search visibility.

How SSL Supports Search Visibility

Google has used HTTPS as a ranking factor since 2014, and its weight has quietly increased over time across multiple algorithm updates. HTTPS sites consistently outperform their HTTP counterparts in search visibility, organic traffic, and engagement metrics across industries.

Beyond ranking, HTTPS also enables faster page load times through HTTP/2 and HTTP/3 protocols, which require HTTPS and provide performance improvements over legacy HTTP/1.1. These faster protocols further boost both user experience and search performance. For any business competing on search visibility or organic traffic, HTTPS is no longer optional or just a “nice to have”; it’s foundational.

The Role of SSL in Reducing Cart Abandonment and Building Customer Confidence

In e-commerce, abandoned shopping carts are a major revenue leakage point, often costing businesses millions annually. When a visitor reaches checkout and sees a browser security warning, lacks visible trust signals, or encounters an SSL error, they abandon their cart.

Conversely, sites with visible SSL indicators (a padlock, the organization name displayed, and no warnings) show significantly higher checkout completion rates and customer confidence. According to GlobalSign research, 77% of website visitors are concerned about data interception or misuse. Sites that visibly address that concern through proper SSL implementation convert more of their visitors into paying customers or users.

Getting Started With Your SSL Certificate

You’ve identified the need for an SSL certificate and understand the available validation levels and certificate types. Next, choose a provider, select the right certificate type and validation level for your business, and install it. Niya Digital’s SSL Certificates Service simplifies the process with clear certificate-type guidance, a straightforward purchase and validation flow, and professional installation support.

Selecting Your First Certificate

Start by identifying your business need and trust requirements. If you run a small business, startup, or non-profit, a Domain Validation certificate offers fast issuance and the lowest cost. If organizational credibility matters significantly to conversions or customer decisions, Organization Validation adds a meaningful trust signal without the extended timeline of Extended Validation. If you’re processing credit card payments, handling sensitive health information, or operating a financial services platform, at minimum, ensure your certificate uses TLS 1.2 or higher, and consider OV or EV to signal strong organizational verification to your customers.

Next, assess your domain structure and growth plans. If you have one primary domain or a small, fixed list of subdomains, a single-domain or wildcard certificate is sufficient and the most cost-effective choice. If you manage multiple unrelated domains, brands, or regional variants, a multi-domain (SAN) certificate consolidates everything into a single certificate and renewal cycle. Then, align your choice with your hosting environment. Some hosting providers include free basic certificates as part of their service; others offer professional SSL installation and management as a paid add-on. Understanding your hosting setup before purchase prevents compatibility surprises and support friction.

The Renewal Cycle and Ongoing Management

Your certificate will expire. Plan for that from day one. If your hosting provider doesn’t support automatic renewal, set a calendar reminder 45 days before expiration as a backup to email notifications. Consider whether managed SSL, where the provider handles validation, installation, and renewal on your behalf, is worth the added cost for your business. For many small teams juggling multiple responsibilities, managed SSL prevents outage risk and eliminates the renewal complexity that often causes certificate expiration incidents.

Frequently Asked Questions

What’s the difference between SSL and TLS?

SSL (Secure Sockets Layer) was the original encryption protocol, developed in the 1990s. TLS (Transport Layer Security) is its modern successor and the industry-standard encryption protocol. Today, people use the terms interchangeably, even though modern certificates technically use TLS, not SSL. Your browser and website negotiate TLS automatically; there’s no practical difference from your perspective. Both provide the same encryption strength and generate the same trust signals.

Can I use a free certificate instead of purchasing one?

Free certificates exist, offered by services like Let’s Encrypt and other sponsored CAs. These certificates provide the same encryption strength as paid certificates. However, free certificates are typically Domain Validation only (no organizational identity), must be renewed frequently (often every 90 days), and lack the organizational verification and customer support services that paid providers offer. For businesses prioritizing convenience, customer support, and professional management, paid certificates are worth the investment.

How long does it take to obtain an SSL certificate?

Domain Validation certificates typically issue in minutes to a few hours; the CA validates your domain ownership automatically and delivers the certificate immediately. Organization Validation certificates usually take 1–3 business days because the CA must verify your business registration through official sources. Extended Validation certificates can take several days or longer due to the more rigorous validation process. Plan your certificate purchase around your go-live timeline, and choose the validation level that matches your urgency.

Will installing an SSL certificate slow down my website?

No. HTTPS has minimal performance overhead, and modern implementations are actually faster than HTTP-only sites. TLS 1.3 uses a single round-trip handshake, reducing connection setup latency significantly. HTTP/2 and HTTP/3 protocols, which require HTTPS, deliver faster page loads than legacy HTTP/1.1. Any small encryption overhead is more than offset by the performance gains provided by modern protocols.

What does “certificate renewal” mean, and how often do I need to do it?

Certificate renewal is the process of obtaining a new SSL certificate before your current one expires. Certificates are typically valid for 1 or 2 years from issuance. As expiration approaches, you purchase a new certificate, go through validation again based on the validation level, and install it on your server before the old certificate expires. Auto-renewal automates this process entirely, renewing and installing your certificate without any manual intervention.

What happens if my SSL certificate expires?

When an SSL certificate expires, it stops being valid. All visitors see a full-page browser warning, “This site’s certificate has expired,” or similar language, and many modern browsers block the page from loading entirely. This is a hard outage, not a gradual degradation. Your site appears broken and potentially unsafe, even though the server itself is working fine. Timely renewal and automatic renewal systems prevent expiration.

Do I need a different certificate for each subdomain?

Not necessarily. A Wildcard certificate covers all first-level subdomains (*.example.com covers api.example.com and mail.example.com but not deep.api.example.com). A SAN certificate can cover multiple distinct domains and specific subdomains. For most websites, one certificate type covers all needed subdomains; you don’t need separate certificates for each subdomain.

Which validation level should I choose, DV, OV, or EV?

Choose based on your visitors’ trust requirements and your business model. For personal projects or internal sites, DV is sufficient. For business websites, professional services, and small-to-medium commerce operations, OV adds meaningful credibility without excessive validation burden. For e-commerce, financial services, healthcare, or any high-trust operation, EV provides the deepest organizational verification. If you handle credit card payments, PCI DSS requirements typically recommend OV or EV for full compliance.

What is a Certificate Signing Request (CSR)?

A Certificate Signing Request is a file your server generates, containing information about your domain and organization. You submit the CSR to the CA along with your certificate application. The CA validates the CSR information, signs it cryptographically, and returns an issued certificate. You then install the certificate and keep the corresponding private key secure. The CSR itself is not sensitive; the private key is and must be protected carefully.

Can I move an SSL certificate from one hosting provider to another?

Certificates are tied to domains and private keys, not to specific hosting providers. If you keep your private key secure, you can export your certificate and install it on any hosting provider that supports it. However, most hosting platforms and resellers keep certificates within their systems. Check with your new provider about certificate portability and export policies before switching hosts to avoid unexpected migration issues or support friction.

Why do I see a mixed content warning after installing SSL?

Mixed content warnings occur when your HTTPS page loads resources (images, scripts, stylesheets) over HTTP. Audit your HTML and CSS for hardcoded “http://” links, and replace them with “https://” or protocol-relative URLs. Test in your browser console (F12 → Console) for mixed content warnings, and fix each one identified. This is common after migrating from HTTP to HTTPS if you don’t update old content.

Does an SSL certificate cover my email domain?

No. SSL certificates secure websites (HTTPS). Email requires separate encryption, typically using STARTTLS or TLS for SMTP and IMAP connections, or S/MIME for message signing and encryption. If your email domain matches your website domain, you’ll still need separate email encryption setup through your email provider or email security service, not through a website SSL certificate. Website and email security are independent layers.

What’s the cost of an SSL certificate?

Pricing varies significantly by validation level, certificate type, number of domains, and provider. Domain Validation certificates start at the lower end of the market. Organization Validation and Extended Validation certificates cost more due to additional verification processes. Multi-domain and wildcard options may cost more than single-domain certificates. Managed SSL services may also cost more. Pricing varies by provider, certificate type, and region; check current plans and providers for specific figures.

How do I monitor SSL certificate expiration?

Set email alerts through your certificate provider’s account portal or your web hosting control panel. Use a third-party SSL monitoring service that monitors your certificate daily and alerts you well before expiration. Enable auto-renewal in your account settings if available. Most providers send automatic reminders 60, 30, 10, and 1 day before expiration. For critical sites, external monitoring catches auto-renewal failures before they cause downtime.

Can I get an SSL certificate for an IP address instead of a domain name?

SSL certificates are designed to protect domain names, not IP addresses directly. If you need to secure an internal service accessed by IP, you must either set up a domain name and DNS record pointing to that IP, then get a certificate for the domain, or use a self-signed certificate (lower trust, no CA cost, not recognized by browsers). For any public-facing service, a domain name and proper CA-issued certificate is the right approach.

Glossary

• Certificate Authority (CA): A trusted third-party organization that verifies domain and organizational identity, then cryptographically signs and issues SSL/TLS certificates. Every major browser maintains a list of trusted CAs; certificates signed by these CAs are recognized worldwide.
• HTTPS: The secure version of HTTP, which uses SSL/TLS encryption to protect data in transit between browser and server. Indicated by a padlock icon and a “Secure” label in the browser address bar. HTTPS encrypts all communication between the visitor’s browser and your web server.
• Mixed Content: A condition where a secure HTTPS page loads one or more resources (images, scripts, stylesheets) over unencrypted HTTP, weakening security and triggering browser warnings or content blocks.
• Public Key Infrastructure (PKI): The cryptographic framework underlying SSL/TLS, based on asymmetric encryption using public and private key pairs. A public key encrypts data; only the corresponding private key can decrypt it.
• TLS (Transport Layer Security): The modern encryption protocol that secures data between browsers and web servers. TLS 1.2 and TLS 1.3 are the current secure versions; older versions like TLS 1.0 and 1.1 are considered insecure.
• Wildcard Certificate: An SSL certificate that secures one base domain and all of its first-level subdomains (e.g., *.example.com secures api.example.com, mail.example.com, and any other *.example.com subdomain).
• SAN (Subject Alternative Name): A field in an SSL certificate that allows it to secure multiple domain names and subdomains within a single certificate, up to 250 names depending on the provider.