Lesson map
Lesson 02 published. Map, example, EX005.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Reaching a site"]
N2["2.2 Certificates"]
N3["2.3 HTTP basics"]
N4["2.4 Redirects"]
N5["2.5 Ports and firewalls"]
N6["2.6 Customer conversations"]
N7["DNS checks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX005"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Reaching a site"]
N2["2.2 Certificates"]
N3["2.3 HTTP basics"]
N4["2.4 Redirects"]
N5["2.5 Ports and firewalls"]
N6["2.6 Customer conversations"]
N7["DNS checks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX005"]
[Learning outcomes]
|
v
[2.1 Reaching a site]
|
v
[2.2 Certificates]
|
v
[2.3 HTTP basics]
|
v
[2.4 Redirects]
|
v
[2.5 Ports and firewalls]
|
v
[2.6 Customer conversations]
|
v
[DNS checks]
|
v
[Worked example] --> [Exercise EX005]
Learning outcomes
You will (1) explain how visitors reach a site over HTTPS; (2) describe DNS, ports and certificates at a practical level; (3) recognise redirects and their risks; (4) read basic request details in support cases.
2.1 Reaching a site
The visitor's device asks DNS for the site's address, connects to port 443, checks the site's certificate and then exchanges encrypted HTTP requests. Each step can fail or be misused, and support technicians often need to tell which step a problem belongs to. Ferncroft's problem sat at the last step, inside the HTTP response, but Tomás still checks the earlier steps. A changed DNS record or a broken certificate can also send visitors somewhere unexpected. Knowing the order lets him rule out each step quickly before blaming the plugin.
2.2 Certificates
A certificate proves the server holds the site's name. Pinecrest renews certificates automatically; expired certificates cause browser warnings that customers report as "the site is broken". Because renewal is automatic, an expired certificate usually means the renewal job failed rather than that someone forgot. Tomás checks the certificate's expiry date in the browser before anything else when a customer reports warnings. A valid certificate also rules out one explanation for strange behaviour, which helped narrow the Ferncroft redirects to the site itself.
2.3 HTTP basics
Requests have a method (GET, POST), a path and headers; responses have a status code: 200 success, 301/302 redirect, 401 needs sign-in, 404 not found, 500 server error. Knowing these codes lets Tomás read logs and customer screenshots quickly. In the Ferncroft screenshots, the status code 302 on image pages was the first technical clue. In the log lab later, the 401 lines on /admin and the 500 lines on /shop tell two different stories from the same file. A 302 alone is normal for http-to-https moves, so the destination domain is what Tomás reads next.
2.4 Redirects
Redirects are normal, for example from http to https. Unexpected redirects to other domains, as Ferncroft's visitors saw, usually mean something on the site has been changed and must be investigated rather than worked around. Working around an unexpected redirect, for example by clearing a cache and closing the ticket, would hide the evidence and leave visitors exposed. At Ferncroft, the 302 from image pages to an unknown domain was the visible effect of the changed mirror copy, and only investigation found that cause.
2.5 Ports and firewalls
Customer servers accept only web traffic publicly; administration uses Pinecrest's private network and multi-factor sign-in. Keeping administration off the public internet means a visitor can reach the shop but not the server's management interfaces. For Ferncroft, this limited what an outsider could do directly. The redirect came from code the site itself was running, installed by support, rather than from someone breaking into the server's administration. Multi-factor sign-in on the private network means a stolen staff password alone does not open a customer server's administration.
2.6 Customer conversations
Tomás learns to ask precise questions: which page, which time, what the browser showed, and whether others see it too. Precise questions save time and avoid guessing. 'The site is broken' could mean an expired certificate, a slow page or a redirect. For Ferncroft, asking which page and what the browser showed produced three screenshots, all of a 302 redirect from product image pages, which pointed straight at image handling. He writes the answers into the ticket, so the security team sees the same facts without asking the customer again.
DNS checks
When redirects appear, Tomás also confirms the site's DNS records still point at Pinecrest, ruling out a changed domain setting.
Worked example
For the Ferncroft case, Tomás collects three customer screenshots. All show a 302 redirect from the product image page to an unknown domain, while other pages load normally. That narrows the problem to image handling, the resize plugin's job, and Grace escalates it to the security team.
Synthetic case. Domains and screenshots are synthetic.
Errors and limits
A redirect can also come from DNS or caching changes; check those too before concluding.
Exercises
- EX005 — Connection steps. What steps happen before an HTTPS page loads?
Show marking criteria
Rubric: 3 = DNS, connect 443, certificate check, encrypted requests; 2 = three; 1 = one; 0 = none. - EX006 — Status codes. What do 302, 401 and 500 mean?
Show marking criteria
Rubric: 3 = redirect, needs sign-in, server error; 2 = two; 1 = one; 0 = none. - EX007 — Unexpected redirect. Why are unexpected redirects investigated?
Show marking criteria
Rubric: 3 = usually mean site was changed; 2 = partial; 1 = vague; 0 = none. - EX008 — Narrowing. How did screenshots narrow the Ferncroft problem?
Show marking criteria
Rubric: 3 = only image page redirected; resize plugin; 2 = partial; 1 = vague; 0 = none.
Synthesis
Knowing protocols lets support narrow problems fast.
Continue studying — chapter 02 of 18
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →