Case: “Hjemmeside ikke sikker” – fra browseradvarsel til stabil HTTPS på 48 timer
En fredag formiddag begyndte en virksomheds hjemmeside pludselig at vise “Ikke sikker” i Chrome. Siden havde i måneder fungeret uden synlige problemer, men nu faldt antallet af kontaktformularer markant, og flere kunder ringede for at spørge, om siden var blevet hacket. Det viste sig, at et SSL-certifikat var udløbet, og at der samtidig var blandet indhold (HTTP-elementer på en HTTPS-side), som holdt advarslen i live – selv efter certifikatet var fornyet.
Casen er typisk: Når en hjemmeside ikke er sikker, handler det ofte ikke om et avanceret angreb, men om kryptering, certifikater og små tekniske detaljer, der ikke bliver fanget i daglig drift. Har man brug for teknisk sparring, kan det være relevant at Få hjælp af et webbureau i Aarhus.

Hvad betyder “ikke sikker” på en hjemmeside?
Når en browser markerer en side som “ikke sikker”, betyder det i praksis, at forbindelsen ikke er krypteret korrekt. Den hyppigste årsag er manglende HTTPS (som kræver et SSL/TLS-certifikat), men advarslen kan også udløses af fejl i certifikatet eller indhold, der stadig hentes via HTTP.
For besøgende er signalet enkelt: “Her bør jeg ikke indtaste oplysninger.” For ejeren kan konsekvensen være større end forventet, fordi advarslen påvirker:
- Tillid (flere forlader siden med det samme)
- Konverteringer (færre formularer, færre køb)
- SEO (lavere klikrate fra Google, og i nogle tilfælde dårligere performance i søgeresultater)
Det er netop derfor søgningen “hjemmeside ikke sikker” er så udbredt: Problemet opstår ofte pludseligt og rammer direkte på forretningen.
Symptomerne i denne case (sådan så fejlen ud i praksis)
Siden viste tre tydelige tegn, som mange genkender:
- Chrome/Edge viste “Ikke sikker” i adressefeltet
- Kontaktformularen blev udfyldt sjældnere fra den dag advarslen dukkede op
- Nogle undersider havde hængelås, mens andre ikke havde (inkonsistent HTTPS)
Det sidste punkt er vigtigt. Hvis kun dele af sitet er på HTTPS, opstår der nemt redirect-loop, mixed content og usikkerhed omkring cookies/sessions – især på WordPress og lignende CMS’er.
Årsagen: Udløbet SSL + mixed content (to fejl, der ofte følges ad)
I casen var der ikke én, men to årsager.
1) SSL-certifikatet var udløbet
Certifikatet havde tidligere været sat op med automatisk fornyelse, men fornyelsen fejlede efter en ændring hos hostingudbyderen. Resultatet: Browseren kunne ikke validere forbindelsen, og advarslen kom med det samme.
Typiske tegn på SSL-problemer:
- Certifikat udløbet
- Certifikatet matcher ikke domænet (fx www vs. uden www)
- Certifikatkæden er ikke komplet (intermediate certificate mangler)
2) Der var blandet indhold (mixed content)
Efter certifikatet blev fornyet, burde siden være “sikker”. Det var den ikke, fordi siden stadig hentede enkelte ressourcer via HTTP, fx:
- Billeder indsat i gamle blogindlæg med
http://
- Et JavaScript fra et ældre plugin
- En font eller tracking-kode med hardcodet HTTP-link
Når en HTTPS-side indlæser elementer via HTTP, ser browseren det som en delvist usikker side. Derfor kan “website ikke sikker” blive ved, selvom HTTPS er aktiveret.
Sådan blev problemet løst (trin-for-trin i praksis)
Løsningen blev gennemført i en fast rækkefølge for at undgå, at fejlen flyttede sig rundt eller kom tilbage ved næste opdatering.
Trin 1: Bekræft hvad der udløser advarslen
Før der ændres noget, bør årsagen identificeres præcist. I casen blev der tjekket:
- Certifikatstatus (gyldighed, domænematch og kæde)
- Console-fejl i browserens udviklerværktøjer (mixed content vises tydeligt)
- Om der var redirects fra HTTP → HTTPS på alle varianter (med/uden www)
Det gav et klart svar: Certifikat var udløbet, og efter fornyelse var der mixed content på udvalgte sider.
Trin 2: Forny/installer SSL korrekt og aktiver HTTPS
Certifikatet blev fornyet og sat korrekt op på serveren. Herefter blev HTTPS gjort til standard, så al trafik automatisk blev sendt til den sikre version.
I praksis betyder det typisk:
- Aktivér SSL i hostingens kontrolpanel
- Tving HTTPS (server-regel eller platform-indstilling)
- Vælg én kanonisk version (fx
https://www.domæne.dk)
Trin 3: Ryd mixed content systematisk
Det var her, den “skjulte” del af problemet lå. Indholdet blev gennemgået og rettet, så alt blev hentet via HTTPS.
De mest effektive greb i casen:
- Opdatér interne links fra
http:// til https:// (især i gamle indlæg)
- Udskift eksterne ressourcer, hvis leverandøren ikke understøtter HTTPS
- Gennemgå tema og plugins for hardcodede HTTP-referencer
- Brug en sikker søg/erstat i databasen, hvor det er nødvendigt (med backup først)
Har du WordPress, kan du med fordel bruge dette plugin: https://wordpress.org/plugins/really-simple-ssl/
Trin 4: Opdatér “site address” og caches (WordPress-scenarie)
På WordPress-lignende opsætninger kan en side stadig opføre sig usikkert, hvis platformen “tror”, den kører på HTTP. Læs også om WordPress sikkerhed her.
Derfor blev:
- Webadresse (WordPress Address/Site Address) sat til
https://
- Cache og CDN-cache ryddet, så gamle HTTP-versioner ikke blev serveret
- Browser-cache testet i inkognito, så resultatet var reelt
Trin 5: Verificér resultatet med konkrete tests
Efter rettelserne blev der kørt en hurtig validering:
- Åbn forsiden og en håndfuld undersider: hængelås vises konsekvent
- Tjek console: ingen mixed content-advarsler
- Test kontaktformular: indsendelse fungerer uden sikkerhedsfejl
- Kontrollér redirects: HTTP sender altid videre til HTTPS
En vigtig detalje: Der kan gå lidt tid, før brugere stopper med at se advarsler, hvis de har cachet den gamle version, eller hvis en proxy/CDN stadig har HTTP-ressourcer liggende.
Resultat: Tillid tilbage – og færre “mystiske” fejl fremover
Efter udbedring blev der set en tydelig normalisering i henvendelser. Derudover forsvandt en række småfejl, der ofte følger med en ustabil opsætning: session-problemer, uens redirects og sporadiske advarsler på enkelte landing pages.
Konklusionen fra casen er enkel: Når “hjemmeside ikke sikker” dukker op, er det sjældent nok bare at installere et certifikat. Den varige løsning kræver, at hele sitet er 100% HTTPS – inklusive billeder, scripts og eksterne integrationer.
Forebyggelse: Sådan undgås at “ikke sikker” kommer tilbage
Der blev implementeret nogle praktiske rutiner, som er realistiske for de fleste små virksomheder:
- Aktivér automatisk certifikatfornyelse og sæt en påmindelse 30 dage før udløb
- Kør månedlig opdatering af CMS, tema og plugins (forældet software er en klassiker)
- Brug stærke adgangskoder og 2FA på admin-login
- Begræns antallet af plugins og fjern dem, der ikke længere bruges
- Tag regelmæssige backups og test, at de kan genskabes
Det mindsker både risikoen for SSL/HTTPS-fejl og de situationer, hvor man ender med at spørge: “Er min hjemmeside hacket?” – selvom problemet i virkeligheden er konfiguration.
FAQ: Hjemmeside ikke sikker
Hvorfor viser Google eller Chrome min side som “ikke sikker”?
Oftest fordi siden mangler HTTPS, SSL-certifikatet er udløbet, eller siden indeholder blandet indhold (HTTP-elementer på en HTTPS-side).
Hvordan fikser man en “ikke sikker” hjemmeside hurtigt?
Start med at kontrollere SSL-certifikatet, aktivér HTTPS på hele domænet og fjern mixed content. Afslut med at teste redirects og rydde cache.
Hvad er mixed content?
Mixed content betyder, at en HTTPS-side henter enkelte ressourcer via HTTP, fx billeder eller scripts. Det kan udløse advarsler, selvom certifikatet er korrekt.
Er en “usikker hjemmeside” altid et tegn på hack?
Nej. Mange tilfælde skyldes udløbet certifikat eller forkert opsætning. Mistanke om hack er relevant, hvis der samtidig er ændret indhold, spam-sider, ukendte brugere eller advarsler i sikkerhedsværktøjer.