Every business site needs HTTPS, every browser now shames the sites that lack it, and yet SSL remains one of the most oversold products in hosting. Companies get talked into a certificate costing hundreds of dirhams a year for a brochure website, or told that an expensive certificate makes their site “more secure” than a free one. Neither is true.
This guide explains what a certificate actually does, what the types genuinely differ on, when paying is justified and when it is not, and the handful of configuration mistakes that leave a site with a valid certificate and a security warning anyway.
Quick Answer
An SSL/TLS certificate does two things: it encrypts traffic between the visitor and your server, and it proves the site is served by whoever controls the domain. For most business websites a free Domain Validated certificate — from Let’s Encrypt, included with any decent hosting — provides exactly the same encryption strength as the most expensive certificate available. What money buys is a stronger identity check, a warranty, and support, none of which most sites need. Pay for a certificate when you have a genuine reason: an Organisation or Extended Validation certificate to display a verified company identity, or a wildcard certificate to cover many subdomains at once.
What a Certificate Actually Does
Two separate jobs, routinely conflated.
Encryption. Without it, everything between the visitor and your server travels in readable form — form submissions, login details, whatever anyone types. On shared Wi-Fi that is trivially interceptable. HTTPS makes it unreadable in transit.
Identity. The certificate is issued by a certificate authority that browsers trust, and it asserts that the server presenting it controls the domain. This is what stops someone impersonating your site with a lookalike server.
The point people miss: the encryption is identical across certificate types. A free Let’s Encrypt certificate and a five-hundred-dirham commercial certificate negotiate the same TLS versions with the same ciphers. Anyone selling you “stronger encryption” for more money is selling something that does not exist.
What differs is how thoroughly the authority checked who you are before issuing.
The Three Validation Levels
Domain Validated (DV). The authority confirms you control the domain — usually by checking a DNS record or a file on the server. Issued in minutes, automatically, free. The padlock looks identical to every other certificate. This is the correct choice for the overwhelming majority of business websites.
Organisation Validated (OV). The authority additionally verifies that your company legally exists — trade licence, registered address, sometimes a phone call. Takes days and costs money. The company details are visible to anyone who inspects the certificate, though no browser surfaces this in the address bar any more.
Extended Validation (EV). The most thorough vetting of the legal entity. Historically browsers displayed the company name in green next to the address; they stopped doing this years ago, which removed the main commercial reason people bought EV. It still carries the strongest identity assertion, and it is still sold on the strength of a visual indicator that no longer exists — be aware of that when someone quotes you for one.
Certificate Scope: Single, Wildcard, Multi-Domain
Separate from validation level, and more likely to matter to you.
Single domain. Covers example.com and usually www.example.com. Fine for one site.
Wildcard. Covers *.example.com — every subdomain at one level: shop., mail., portal., staging.. If you run several subdomains this is the practical choice, and it is a genuine reason to pay, though free wildcard certificates are also available with DNS-based validation.
Multi-domain (SAN). Covers several different domains on one certificate. Useful if you operate multiple brands on the same server.
The scope mistake: a wildcard for *.example.com does not cover a.b.example.com — wildcards match one level only. Businesses with nested subdomains hit this and assume the certificate is broken.
When Paying Is Justified
Free DV certificates cover most needs. Pay when one of these applies:
You need a verified organisation identity in the certificate. Some enterprise procurement processes, some financial and government tenders, and some partner integrations require OV or EV. If a contract asks for it, that is a real requirement.
You need a warranty. Commercial certificates carry a financial warranty against mis-issuance. This matters to a payment processor, not to a company brochure site.
You need support and a longer operational cycle. Free certificates are short-lived and renew automatically. If your setup cannot automate renewal — an appliance, an unusual platform, a system nobody maintains — a manually installed longer-lived certificate can be less risky in practice.
You need a wildcard and cannot do DNS-based validation. Automated wildcards require API access to your DNS. If your DNS is somewhere that does not offer it, buying is simpler.
If none of those apply, a free certificate is the correct engineering answer, not a compromise.
The Mistakes That Break HTTPS Anyway
A valid certificate does not guarantee a working padlock. These are what we actually find:
Mixed content. The page loads over HTTPS but pulls an image, script or stylesheet over HTTP. Browsers flag the page as not fully secure, and block some resources outright. Almost always caused by hard-coded http:// URLs left in content or theme settings after a site moved to HTTPS.
No redirect from HTTP to HTTPS. Both versions load, so the insecure one stays reachable and indexable — and you now have two versions of every page competing in search. A single site-wide redirect fixes it.
Only one hostname covered. The certificate covers example.com but the site is reachable at www.example.com, or the reverse. Visitors on the uncovered hostname get a full-page browser warning — the most damaging failure on this list, because it looks exactly like a compromised site.
An incomplete certificate chain. The server sends its certificate but not the intermediate certificate above it. Desktop browsers often paper over this; mobile browsers and API clients frequently do not. The classic symptom is “it works on my laptop but the app cannot connect.”
Expiry. Still, in 2026, a leading cause of sudden outages. Automated renewal exists precisely so this cannot happen — confirm it is actually running rather than assuming.
Subdomains nobody remembers. A staging or legacy subdomain with an expired certificate produces warnings for anyone who reaches it, and looks like a compromise from the outside.
Check Your Own Site
Five minutes, and you need nothing but a browser:
1. Load your site over https://. Padlock present and no warning?
2. Load it with and without www. Both should work and both should end up on the same address.
3. Load it over http://. It should redirect to HTTPS, not simply load.
4. Click the padlock and check the expiry date, and confirm renewal is automated.
5. Run a public SSL test tool against your domain. It will report chain problems and weak configurations a browser hides from you.
6. Repeat for every subdomain you own — including the ones you forgot about.
Where We Fit
BIGBANG ITS includes certificates with hosting, configures the redirect and the chain properly, and monitors expiry so renewal is not something anybody has to remember. We also sell commercial certificates where a client genuinely needs one — and we will tell you when you do not, because selling an EV certificate to a company brochure site is not a service.
If you are not sure whether your site’s HTTPS is set up correctly, or you have been quoted for a certificate and want an independent view on whether you need it, ask us.
