An SSL certificates are used to make your personal information protected, particularly when it comes to online transactions. It’s a mechanism that works between a user’s browser and the website the user is connecting to. In its software, the website has an SSL certificate issued by a trustworthy authority. Web browsers (i.e. Internet Explorer®, Firefox® and Chrome™) recognize these certificates. When confidential info needs to be exchanged, SSL is used to encrypt the information before it is sent, and then to decrypt it at the other end, when it has been received.
This ensure that the website activity, from its own sensitive information to that of its browser is secure. This is especially important if the business is involved in handling online transaction. Online Buyers and visitor know this stuff. Banks, for instance, have warned them to check for the small padlock icon that appears on their browser screen when SSL is in use

Dani AI

Generated

Technical clarifications and a short deployment checklist based on the thread.

The term “SSL” is used broadly, but the protocol layer that matters today is TLS. Disable legacy protocol versions (SSLv2/SSLv3, TLS 1.0/1.1) and prefer TLS 1.3 where available (TLS 1.2 minimum). Beyond encryption, a properly configured certificate and TLS stack provide server authentication, integrity, forward secrecy and access to browser-only features (HTTP/2, service workers, secure cookies).

Common operational pitfalls that cause trust warnings or outages are: missing intermediate certificates, expired or mis‑issued certs, incorrect SAN/CN entries, mixed (HTTP) content on HTTPS pages, and terminating TLS at a load‑balancer without securing backend links. Quick verification commands that are useful from CI or an admin shell:

# show server chain and certs
echo | openssl s_client -connect example.com:443 -servername example.com -showcerts

# check certificate expiry
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Operational best practices: automate issuance/renewal (ACME clients or host-managed certs), enable OCSP stapling, prefer ECDHE with AEAD ciphers (AES-GCM or ChaCha20-Poly1305) for forward secrecy, and add an HSTS header only after verifying redirects and every subdomain:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

(Do not request preload until every subdomain is HTTPS-ready — preload is effectively permanent.)

Quick checklist:

  • Server presents full chain and correct SANs
  • TLS 1.2+ (prefer 1.3) with forward secrecy and AEAD ciphers
  • No mixed content; all HTTP -> HTTPS 301 redirects
  • OCSP stapling enabled; expiry/renewal automated and monitored
  • HSTS configured and preload only after testing

This complements points raised by , , , , and by focusing on the operational/configuration issues that cause most real-world failures.

Recommended Answers

All 6 Replies

Indeed. And you can get them without hassle and totally free of charge from Let's Encrypt without having to use some commercial outfit which charges silly money. Just saying...

If you're hosting a website then your hosting provider will definitely have a free SSL option. and if they don't then you're with a shitty provider and you need to bail already lol.

besides HTTPS is a ranking factor now even if not one of the main ones...

i wasnt aware of the free ssl option....thanks

Referring to your title of Question..
1- All websites are online

  1. Not all websites need SSL. Only who are using online money transcations need a secure line to safe clients from internet theft.

Not so. All sites require a SSL cert unless they are happy being either flagged as insecure by web browsers (or the user refused a connection) and being hit with a search ranking penalty. Your comment is now very dated indeed I'm afraid afia_1

commented: Be not afraid of telling the truth. +15

All e-commerce sites require SSL, otherwise people can skim your user's credentials as well as their Credit card numbers. Essentially they craft a regex that matches the credit card number that is applied to a certain page which is returned to the server. The man in the middle acquires the card info, and stores it for later usage and or sale on the dark web. From what I understand you buy the SSL cert from a Certificate Authority, and your admin should plug in the certificate to your IIS server somehow. Have been looking for a good demonstration of this, as I will probably be plugging in my own test cert for my testing on my local VM box.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.