Hvad er HTTPS og SSL? Sådan fungerer sikre websites, forklaret enkelt

HTTPS er den sikre version af HTTP, den protokol browsere bruger til at tale med websites. Den pakker hver forespørgsel og hvert svar ind i en krypteret forbindelse ved hjælp af TLS (Transport Layer Security), så ingen mellem besøgende og website kan læse eller manipulere med det, der sendes. SSL er det ældre navn for den samme idé – den oprindelige protokol, TLS erstattede – og derfor siger folk stadig „SSL-certifikat“.

Hvorfor HTTPS betyder noget, når du bygger med AI

Enhver app, du udgiver, bør serveres over HTTPS. Det er ikke kun god praksis:

• Browsere forventer det. Sites på almindelig HTTP bliver markeret som „Ikke sikker“, og nogle browserfunktioner – fx adgang til placering, kamera og mikrofon samt service workers til offline-apps – virker generelt kun på sikre (HTTPS) sider.
• Login og formularer. Uden HTTPS sendes adgangskoder, session-cookies og formulardata i læsbar tekst. Hvem som helst på det samme café-wifi kan potentielt opfange dem.
• Betalinger og tredjeparter. Betalingsudbydere, OAuth-login og mange API'er kræver HTTPS-redirect- og callback-URL'er.
• Tillid og søgning. Besøgende lægger mærke til advarslen, og Google har sagt, at de bruger HTTPS som et rangeringssignal.

Det gode nyt er, at HTTPS på de fleste moderne hostingplatforme er sat op automatisk. Det, du mest har brug for, er at forstå delene godt nok til at rette det, når et eget domæne eller en advarsel om blandet indhold går galt.

En hverdagsanalogi

At sende data over almindelig HTTP er som at sende et postkort: hver postmedarbejder, der håndterer det, kan læse det, og nogen kan endda ændre budskabet.

HTTPS er som at sende et forseglet, manipulationssikkert brev – og først tjekke modtagerens officielle ID. Certifikatet er det ID-kort, der er udstedt af en betroet myndighed (certifikatmyndigheden), som har kontrolleret, at websitet virkelig råder over domænet. Krypteringen er den forseglede konvolut. ID'et beviser, at du skriver til den rigtige adresse; konvolutten holder indholdet privat.

Sådan virker HTTPS, enkelt forklaret

Når en browser åbner https://shop.example.com:

1. Hej. Browseren forbinder og oplyser, hvilke krypteringsmetoder den understøtter.
2. Certifikat. Serveren sender sit certifikat, som siger „denne nøgle tilhører shop.example.com“, og er underskrevet af en certifikatmyndighed.
3. Kontrol. Browseren verificerer underskriften over for myndigheder, den allerede stoler på, tjekker at certifikatet ikke er udløbet, og at domænet matcher.
4. Nøgler. Browser og server bliver enige om en ny hemmelig nøgle til sessionen, uden nogensinde at sende den åbent.
5. Krypteret samtale. Alle forespørgsler og svar – sider, formulardata, cookies – sendes nu krypteret.

Dette TLS-håndtryk tager et par millisekunder og sker automatisk. Den besøgende ser blot hængelåse-ikonet (eller, i nogle browsere, et neutralt site-info-ikon).

Hvad HTTPS beskytter og ikke beskytter

HTTPS krypterer indholdet af forespørgsler, inklusive sidestien og query-strengen. Men domænenavnet, du besøger, er som regel stadig synligt for netværk undervejs. Det er en af grundene til aldrig at putte personlige data i URL'er – de ender også i logfiler og browserhistorik.

Et konkret eksempel: forbind et eget domæne

Antag, at du udgiver en booking-app og vil have den på book.myyogastudio.com:

1. Du tilføjer en DNS-post, der peger book.myyogastudio.com mod din host. Se hvordan domæner og DNS virker.
2. Hosten beviser over for en certifikatmyndighed, at den kontrollerer navnet – typisk ved at svare på en udfordring på domænet – og modtager et certifikat.
3. Hosten installerer det og fornyer det automatisk, før det udløber. Certifikater er bevidst kortlivede, så automatisk fornyelse er vigtig.
4. Besøgende på http://book.myyogastudio.com omdirigeres til https://.

Hvis trin 1 er forkert – posten peger et andet sted, eller en proxy står i midten – kan trin 2 fejle, og de besøgende ser en certifikatfejl. Det er det mest almindelige HTTPS-problem, folk støder på, når de forbinder et eget domæne.

Centrale begreber

Almindelige misforståelser

• „Hængelåsen betyder, at siden er troværdig.“ Den betyder, at forbindelsen er privat, og at domænet matcher. Svindlere får også certifikater.
• „HTTPS er kun nødvendigt på betalingssider.“ Enhver side med login, formular eller cookie har brug for det – og det er næsten enhver app. Brug det overalt.
• „Certifikater er dyre.“ Gratis, betroede certifikater er standard, og de fleste hosts håndterer dem for dig.
• „HTTPS gør min app sikker.“ Det sikrer forbindelsen. Din app har stadig brug for tilladelsestjek på serversiden, sikker håndtering af hemmeligheder og inputvalidering. Se sikkerhedstjeklisten for AI-byggede apps.
• „HTTPS gør sites langsomme.“ Moderne TLS tilføjer meget lidt overhead, og funktioner som HTTP/2, der gør sites hurtigere, kræver generelt HTTPS i browsere.

Rettelse af almindelige HTTPS-problemer

Hvad du kan bede din AI-builder om

• „Sørg for, at alle billeder, scripts og fonte indlæses over HTTPS eller med relative URL'er – ingen http://-links.“
• „Omdiriger al HTTP-trafik til HTTPS.“
• „Sæt session-cookies med flagene Secure og HttpOnly.“
• „Brug https:// til alle OAuth-, betalings- og webhook-callback-URL'er.“
• „Mit eget domæne viser en certifikatfejl – hvilken DNS-post forventer hosten?“

HTTPS i Mythex

Når du forbinder et eget domæne i Mythex (en Pro-funktion), tilføjer du en CNAME-post, der peger på det slug.mythex.ai-mål, Mythex viser dig, klikker på Verify, og Mythex udsteder HTTPS for domænet automatisk. Dokumentationen dækker de to hyppigste faldgruber: hvis din DNS ligger hos Cloudflare, skal posten stå på „DNS only“ (grå sky) i stedet for proxied, så Mythex kan udstede certifikatet; og DNS kan blive verificeret, før HTTPS er fuldt sat op, så vent et par minutter og verificer igen. Se custom domains i dokumentationen og vores guide til at forbinde et eget domæne.

Spørgsmål