When a user opens a website over HTTPS, the browser and server agree on the parameters of a secure connection. The server confirms its identity with a digital certificate, after which both sides create session keys and begin exchanging encrypted HTTP requests and responses. Without those keys, intercepted traffic is practically impossible to read or alter without detection.
In everyday use, this process is still often called SSL encryption, while the digital certificate is known as an SSL certificate. Modern websites actually use TLS. SSL was its predecessor and is no longer considered a secure protocol.
What Is the Difference Between SSL, TLS, and HTTPS?
SSL, or Secure Sockets Layer, was an early protocol for protecting network connections. All of its versions are now outdated and should not be used by modern websites. The terms “SSL certificate” and “SSL encryption” remain common mainly because people are familiar with them.
TLS, or Transport Layer Security, is the current protocol used to create a secure channel between a client and a server. During the TLS handshake, both sides choose the protocol version and cryptographic algorithms, verify the server, and generate keys. Today, TLS 1.2 and TLS 1.3 are the versions used most often.
HTTPS is regular HTTP traffic transmitted inside a TLS connection. HTTP defines how the browser and server exchange requests and responses, the certificate helps verify the server, and TLS protects the communication channel itself.
What Does an SSL Certificate Do?
An SSL certificate is a digital document containing information about the domain, a public key, its validity period, details about the issuer, and the issuer’s digital signature. It does not encrypt all traffic by itself. Its main purpose is to help the browser verify that the public key really belongs to the server for the requested domain.
The level of verification depends on the certificate type. A DV certificate confirms control over the domain but does not verify the legal identity of its owner. An OV certificate also includes verification of the organisation. Both provide full encryption. The difference lies in the amount of verified information.
The public key is included in the certificate, while the corresponding private key remains on the server. The server proves that it owns this key pair, and the certificate authority’s digital signature confirms that the certificate is authentic.
Browsers and operating systems contain lists of trusted root certificates. A website certificate is connected to one of them through one or more intermediate certificates. If part of this chain is missing, the website may display an error even though the domain certificate itself is still valid.
How the TLS Handshake Works Between a Browser and Server
The TLS handshake takes place before the main data exchange begins. Some details differ between TLS 1.2 and TLS 1.3, but the general sequence is similar.
- The browser sends the connection parameters. In the ClientHello message, it provides the supported TLS versions, cryptographic parameters, and service data. Passwords, form contents, and a ready-made session key are not sent at this stage.
- The server selects the parameters and sends its certificate. In the ServerHello response, it chooses the protocol version and algorithms, sends the certificate chain, and provides the data needed to establish the keys. If there are no compatible parameters, the connection is terminated.
- The browser verifies the certificate. It checks the domain, validity period, digital signature, and chain of trust. When possible, it also checks whether the certificate has been revoked. A critical error results in a warning about an unsafe connection.
- Both sides create a shared secret. The browser and server exchange cryptographic data and separately calculate the same shared secret, which is then used to derive session keys. In a typical TLS 1.3 connection, the browser does not simply send a ready-made secret key encrypted with the server’s public RSA key.
- Encrypted communication begins. Once the handshake is complete, both sides switch to fast symmetric encryption for HTTP requests and responses. Session keys are linked to a specific connection, not to the certificate’s validity period.
Why TLS Uses Different Types of Encryption
| Approach | Where it is used | What it does | Why it is not used alone |
| Asymmetric cryptography | Authentication and key agreement | Uses public and private keys and helps verify the server | Requires more computing resources |
| Symmetric cryptography | Main data exchange after the handshake | Encrypts traffic quickly and protects its integrity | Both sides must first obtain shared keys securely |
A public key can be shared, while the private key must remain with its owner. Asymmetric cryptography allows the server to prove that it owns the key and take part in creating a shared secret. Using it for the continuous transfer of large amounts of data would require too many resources.
After the handshake, the agreed session keys protect pages, HTTP headers, cookies, forms, and API responses. Symmetric encryption is considerably faster and can also detect whether data was changed during transmission.
What Data Does HTTPS Protect?
HTTPS protects usernames, passwords, payment and contact details, form contents, cookies, HTTP headers, page paths, request parameters, and server responses. IP addresses, connection times, and the approximate volume of traffic may still remain visible on the network. In some cases, the domain can also be seen. The actual request content remains encrypted.
At the same time, HTTPS does not fix website vulnerabilities, malware on a user’s device, phishing, or a database leak after the server has been compromised. It protects information while it is being transmitted, but it does not replace software updates, access control, backups, and other security measures.
TLS encryption provides three main properties of a secure connection:
- Confidentiality. Intercepted traffic appears as an encrypted data stream. Without the required keys, a password, message, or server response cannot simply be read.
- Integrity. TLS makes it possible to detect changes to the data. If someone tries to replace payment details or inject code into a page during transmission, the cryptographic check will fail.
- Authentication. The browser verifies that the certificate matches the requested domain and is connected to a trusted certificate authority. This reduces the risk of connecting to a server pretending to be the legitimate website.
Can Data Protected by HTTPS Be Intercepted?
Network traffic can be recorded, but with a correctly configured TLS 1.2 or TLS 1.3 connection, reading it without the keys is practically impossible. The operator of an ordinary public Wi-Fi network does not automatically gain access to passwords, form contents, or opened pages.
Real risks are more often connected with an expired or incorrectly installed certificate, outdated protocols, a compromised server, phishing, malware, or ignored browser warnings.
On managed corporate devices, traffic may sometimes be inspected through a specially installed trusted certificate. In that case, the company’s system deliberately acts as an intermediary for that device.
How to Check Whether a Website Connection Is Secure
The website address should begin with https://. The browser usually allows you to open connection and certificate details beside the address bar. However, the lock icon alone is not enough: a phishing website can also have a valid certificate for its own domain.
Check the address carefully. It should not contain extra words, replaced letters, or an unusual domain ending. The certificate details show which domains it covers, its validity period, and the certificate authority that issued it.
Do not enter a password, payment details, or personal information after a critical browser warning. First check the address and the date and time on the device. The website owner should fix the certificate or server configuration instead of advising users to bypass the warning.
Common SSL/TLS Problems on Websites
Problems with secure connections are most often caused not by TLS itself, but by incorrect installation or a certificate that was not renewed in time.
- Expired or invalid certificate. Once the validity period ends, browsers display a warning, while applications and APIs may refuse to connect. The certificate must be renewed, and the server should be checked to ensure it uses the new file.
- Incomplete certificate chain. Without the required intermediate certificate, a website may work on some devices but fail on others. The full chain supplied by the certificate authority must be installed on the server.
- Domain name mismatch. The certificate must cover the exact website name, including the required versions with www, without it, and any necessary subdomains.
- Mixed content. If an HTTPS page loads images, scripts, or styles over HTTP, the browser may block them. Internal URLs, templates, database records, and external connections must be updated.
- Outdated protocols and algorithms. SSL, TLS 1.0, TLS 1.1, and weak algorithms should be disabled. The server should use modern TLS 1.2 and TLS 1.3 settings, taking its software version and required compatibility into account.
Which Websites Need an SSL Certificate?
HTTPS is not only necessary for online stores. Even a basic contact form transmits a name, email address, phone number, or message. TLS also protects the page itself from being modified while it is delivered to the user.
An SSL certificate is needed for corporate websites, blogs, user accounts, forums, APIs, administration panels, web services, and landing pages. HTTP should generally be left only for automatic redirection to HTTPS.
How to Choose an SSL Certificate for a Website
The choice depends on the number of domains and subdomains, the verification level, and the structure of the project. A higher price does not automatically mean stronger encryption.
A single-domain certificate is suitable for one main website. Before ordering, check whether it covers both the address with www and the version without it. DV confirms control over the domain, while OV also includes verified organisation details.
A Wildcard certificate is useful when the website has several subdomains at the same level, such as a user account, mail service, and support section. This type of certificate usually does not cover nested subdomains at the next level.
A multi-domain SAN certificate allows several different domains and subdomains to be protected with one certificate. On the RX-NAME SSL certificate page, you can compare the available options and choose a certificate that matches the structure of your website.
Frequently Asked Questions About SSL/TLS Encryption
Can the Owner of a Wi-Fi Network See Data Sent Over HTTPS?
They may see that a connection exists, along with IP addresses, the time, and the approximate amount of traffic. Passwords, form contents, and page contents remain encrypted when HTTPS is working correctly.
Does SSL Encrypt All Data on a Website?
TLS encrypts information while it is transmitted between the client and server. Data stored in databases, files, logs, or backups requires separate protection.
How Is TLS 1.3 Different From Earlier Versions?
TLS 1.3 removed outdated mechanisms, simplified the set of algorithms, and reduced the time needed to establish a new connection. Many servers also support TLS 1.2 for compatibility.
Does an SSL Certificate Affect Website Speed?
The handshake and encryption require some resources, but on modern systems the overhead is usually small. TLS 1.3 and session resumption reduce delays further.
What Happens When the Certificate Expires?
Browsers display a warning, and some clients refuse to connect at all. The certificate should be renewed before its validity period ends.
Is HTTPS Enough to Protect a Website Completely?
No. CMS and plugin updates, strong passwords, access control, backups, server protection, and monitoring are also required.
Conclusion
During an HTTPS connection, the browser and server agree on the TLS parameters, verify the certificate, and generate keys. Once the handshake is complete, HTTP requests and responses are transmitted using fast symmetric encryption.
TLS provides confidentiality, data integrity, and server authentication, but it protects the communication channel itself. It should be one part of a broader website security system.
Check that every page opens over HTTPS without warnings. If there is no certificate, it is close to expiring, or it does not cover the required domains, review the SSL certificates available from RX-NAME and choose an option that matches your project structure.
Leave a Reply