An SSL certificate is a document issued to a domain name that proves which server owns the name and lets browser and server encrypt their traffic. Its cover ends where the data lands, so the decision for your site turns on which page collects what from a visitor. On Tahlil.com, a patient’s test value is encrypted on the way in, then sits on the server as a record the doctor’s panel reads.
SSL certificates: what the name means and what the certificate does
The name is older than the technology now behind it. SSL, Secure Sockets Layer, was the protocol that used to encrypt web connections. TLS, Transport Layer Security, took over that work, yet the document kept its original label, which is why an SSL certificate and a TLS certificate turn out to be the same thing. HTTPS belongs to the same family of terms: web pages travel over HTTP, and when HTTP runs inside the encrypted connection the result is called HTTPS, visible as the https:// at the start of an address. In the rest of this article the document is simply the certificate.
What the certificate does follows from what it contains. Written into it are the address it was issued for and the public key of the server answering there, and an independent body has signed the whole. Your browser keeps its own list of signing bodies it trusts and checks the signature against that list. A valid signature settles identity, meaning the name in the address bar really belongs to the server you reached. It also opens the way to encryption, a connection whose contents nothing along the route can read. The certificate’s tie to an address and its expiry date both come out of this same structure, and anything else owners hope a certificate will do belongs to other tools, as later sections show.
Browsers report the outcome with a mark in the address bar, in some of them a padlock. Whatever its shape, the mark vouches for the connection being encrypted and the certificate being valid at the moment the page loaded. Ownership and content lie outside what it vouches for.
For this site, the commitment is written into our privacy notice. Pages are served over HTTPS, traffic between a visitor’s browser and our server is therefore encrypted, and the section on the quote form repeats the point. Everything in this article stays inside that commitment.
A certificate is issued to an address, not to a page
When a connection opens, the browser holds the name in the address bar up against the names listed in the certificate, and the comparison works name by name rather than page by page. Whether an enquiry form or an admin panel needs a certificate of its own therefore depends on the address it opens under. Served from the same address as your showcase pages, they share one certificate, and no certificate is ever issued to a single page. A panel at a path under your main address is covered already; a panel on another name brings that name’s question with it. Comparing by name also has a consequence owners trip over: a name with www in front and the same name without it count as different names, so a certificate that lists only one leaves visitors on the other facing a warning. How separate systems sit on subdomains under a single name is the subject of our article on domain names.
Diotek shows the rule at work. Diotek’s site-survey and service-request flows run inside the same application as its showcase pages, and the whole site opens from one live address. Under the general rule, a visitor who browses those pages and then leaves a request never crosses into another name, so the certificate question for such a site comes down to one address. Put a form or a panel on its own subdomain as a separate system and the picture changes, because that subdomain carries its own certificate question.
Our own server file looks at the same issue from the other side. Every host apart from the main name, www included, is sent to the main address in one hop. Any rule for a retired address is placed ahead of the www and HTTPS rules, so that an old address reaches its final destination in a single hop whatever host or scheme it arrives with.
Since a certificate is bound to a name, choosing the main name and settling the certificate are questions that belong in the same conversation.
The ‘Not secure’ label reports a missing certificate or the state of the connection
It is tempting to read the warning as being about forms, since a site made only of showcase pages seems to have nothing worth protecting. That reading fails. The “Not secure” label is a judgement on the connection, and a page that loads over HTTP, with no encrypted connection set up, receives it whatever the page contains. Visitors therefore meet it on the first page they open. One browser maker’s help page states the remedy plainly: the owner serves the site over HTTPS. For a site without forms, the reason to have a certificate is the label itself rather than any data in need of protection.
The present scope arrived in stages. Going by that maker’s own announcements, the label was first attached to HTTP pages carrying password or card fields, later to HTTP pages where someone typed data in, and the maker said from the beginning that the target was every HTTP page. That target is where things now stand. The same maker has since announced that its browser will, by default, ask for permission before a first visit to any public site lacking HTTPS, so the trend runs towards stricter treatment.
Holding a certificate does not rule the warning out. A different browser maker’s support document lists when its warning appears on encrypted sites too: the certificate has expired or is illegitimate, or it is valid while the connection runs on an outdated protocol version. Keeping a certificate valid is ongoing work rather than a purchase made once. That same support document also speaks to visitors, telling people never to enter a password or card number on an unencrypted page that asks for one, so whoever reaches your form hears it from the browser before they hear anything from you.
A clean address bar, for its part, says little about the site itself. The label looks at the connection only. Who runs the site and whether its content is accurate are questions it never asks.
A certificate encrypts the route, not the record kept on the server
Encryption covers a stretch of road that starts in the visitor’s browser and finishes at your server. There the data is decrypted and handed to the application, which writes it down as a record, and past that point the certificate has no say. Which people can open the record, which machine stores it and whether a backup exists are settled by the application and the hosting. A certificate answers the question of whether data is safe only for the part spent in transit.
Tahlil.com is a health platform where a value a patient enters becomes a record in the doctor’s panel, and it shows the split clearly. The patient types a test value into the website, and the interpretation is then written and approved in the doctor’s panel. Between browser and server the value travels encrypted. From then on it is a record, read alike by the patient-facing site, the doctor’s panel and the mobile app, and nothing in the address bar describes how that record is kept. A test result spends a moment in transit and far longer in storage, which is why encrypting the route is necessary for such data without being enough.
On our own quote form, an uploaded document is held in a directory the web server keeps off the internet, unreachable by any web address, and that protection comes from a server-side rule rather than from the certificate; the article on which server holds your data describes the rule. Backups are another part of looking after a stored record and fall equally outside a certificate’s scope, so backing up the stored record and restoring it has an article of its own.
The reverse holds as well. A site protected by a certificate can leave a file with careless permissions readable from the internet, while a server with no certificate at all can keep a record properly locked. These tasks belong to different tools, and one cannot do the other’s job. The address-bar mark speaks only for the connection.
Which page carries what: go through your site page by page
To use this on your own site, sort the pages by type and ask one thing of each: what does the visitor send to the server? That is the only cargo a certificate protects, and only on the way. What becomes of it afterwards gets a column of its own below. Rows are named by page type so that they map onto your site; the final column gives the portfolio project behind a row, and a row without one is left blank.
| Page type | What travels from visitor to server | What the certificate protects in transit | What the certificate leaves unanswered | From our portfolio |
|---|---|---|---|---|
| Showcase or catalogue page | Nothing from the visitor; the page travels from server to visitor | Confirmation that the page comes from your address, and that nobody reads it on the way | No record about the visitor is created; even so, a page loaded over HTTP gets the “Not secure” label | |
| Enquiry form page | A date requested for a survey of the premises, details of an installed unit, a written request left by the visitor | Those fields cannot be read in transit | Where the written record that reaches the operations team is kept, and who reads it | Diotek: site survey and service request |
| Page where a health value is entered, and the panel where the interpretation is written | The patient’s test value; the doctor’s interpretation and approval | The value and the interpretation cannot be read in transit | How the record is held in the panel; several interfaces reading one record is the application’s work | Tahlil.com: value entry and doctor’s panel |
| Page that scans a code with the camera and asks for location | The identity carried by the scanned code, and the location at that moment | A web browser hands camera and location to a page only over a secure connection and with permission (the conditions are set out in the mobile website article); a page without a certificate never gets them | Which site the record is written to, and who reads it | Construction-site entry and exit app: an app on the phone that joins the code’s identity and the phone’s location in one record |
| Our own quote form | Form fields and the uploaded document | All traffic between browser and server | Where the document sits on the server: a directory no web address can reach | Algoriel quote form |
Reading across, the protected column barely moves: whatever the page, the certificate does the same work in transit. The cargo grows heavier further down, and what changes is the right-hand question of where the record lives and who reads it. The showcase row is the odd one out. Nothing goes from the visitor, yet the page still needs a certificate, because the browser applies the label without checking for a form. Its portfolio cell is empty on purpose, since an invented example would be worse than a gap.
Diotek’s project record lists what its request side takes in: a date for surveying the premises, the installed unit, and a written request a visitor can leave even when the phone line is engaged. The enquiry row stops there. Your own form will ask for other things; put them in the row and the certificate’s share of the job sits next to the record your server ends up holding.
Two jobs that remain after a certificate is installed: redirecting the old address and tracking the expiry
Expiry comes first, because it catches owners who think the job is finished. When a certificate runs out, browsers stop accepting it and the “Not secure” label returns, even though no line of the site’s code has changed since yesterday. Renewal therefore needs a written answer from whoever runs the project: which account it depends on, and who holds the login. This article does not name that account for any portfolio project; on yours, settle it before handover.
In our own setup, a working certificate appears as its own row in the list of prerequisites prepared once in the hosting account ahead of launch, and the check is simply to open the site and look at the address bar. Which body issues the certificate is beside the point there. What the row records is that the certificate is on.
Redirecting is the other job. A certificate makes HTTPS possible but leaves HTTP working, so a visitor following an old http link needs a rule that forwards the request to the HTTPS address, ideally in one hop. Ours, in the site’s server file, fires only when the connection is not HTTPS and the scheme header forwarded by a proxy in front of the server does not say HTTPS either. The header check is there for setups behind a proxy, where an encrypted visit can still reach the server looking like HTTP; checking the connection alone would bounce such a request for nothing.
Where the hosting panel already handles the redirect, that condition never comes true and our rule stays idle, which is how it should behave. Trouble starts when the redirect lives in more than one place. A “force HTTPS” switch in the panel combined with a server file doing the same work can trap the browser in a redirect loop, a case our deployment document names in its troubleshooting table together with the cure: turn one of them off. One redirect, set up once, is the goal.
The browser-side companion to the redirect is the HSTS response header, which tells the browser to stop using HTTP for the address; our file sends it only while HTTPS is active and deliberately omits the preload option, because reversing it takes a long time.
The certificate question is asked together with the page plan
A quote that says “SSL included” answers less than it seems to. More useful is a list of which page will carry which information and at what address each page will live, because those answers decide where, and how often, the certificate question comes up. A form built into the same application and address as the showcase pages settles it once, and a form added later lands on an address that is ready instead of introducing a new name. A form or panel moved later into a separate system on its own subdomain reopens the question, which can be a perfectly good decision as long as it shows up in the plan.
Diotek is the working example: visitors open each kind of request from the site in a flow of its own. Why those flows were kept separate is a different question, answered in the article on separating appointments from service requests.
Showcase pages and enquiry forms kept in one application are what our corporate website service covers, and larger builds, with forms, panels and server-side rules written into the same application, fall under web development.
Planning a new site, or a rebuild of the one you have? In the quote form, give your current address in the company step and your page list in the project step, noting beside each page what it will take from a visitor; the certificate question can then be handled per address instead of page by page.
