Feilsøke SSL- og HTTPS-feil

En nettleseradvarsel kan skyldes alt fra et utløpt sertifikat til at et CDN viser sertifikatet for feil kunde. Ikke start med tilfeldig gjenutstedelse. Finn den nøyaktige adressen, feilkoden og komponenten som avslutter TLS-forbindelsen.

Be aldri vanlige brukere klikke forbi en sertifikatadvarsel. Da lærer dere dem å ignorere samme varsel ved et reelt angrep.

Første fem minutter

1. Kopier hele URL-en som feiler, inkludert www eller underdomene.
2. Noter nettleserens eksakte feilkode og klokkeslett.
3. Test fra en annen enhet eller et annet nettverk uten å omgå varselet.
4. Kontroller DNS-svaret for vertsnavnet.
5. Finn hvor TLS termineres: CDN, proxy, lastbalanserer, plattform eller origin-server.
6. Se sertifikatet som faktisk leveres eksternt, ikke bare filen som ligger på serveren.
7. Dokumenter siste endring i DNS, hosting, proxy, sertifikat eller redirect.

Hvis nettstedet nettopp er flyttet, kan ulike DNS-svar føre brukere til gammel og ny infrastruktur samtidig. Begge må enten ha gyldig sertifikat i overgangsperioden, eller DNS-endringen må planlegges slik at gammel tjeneste ikke tas ned for tidlig.

Rask feiltabell

Feil 1: Sertifikatet er utløpt eller ikke gyldig ennå

Kontroller både notBefore og notAfter. En feil systemklokke på klienten kan få et gyldig sertifikat til å se ugyldig ut, men hvis flere uavhengige klienter ser samme feil, ligger årsaken normalt i leveransen.

Ved utløp:

1. Finn hvilken ACME-konto eller leverandør som skulle fornyet sertifikatet.
2. Les siste fornyelseslogg og feilmelding.
3. Rett valideringsproblemet før ny bestilling.
4. Utsted eller forny sertifikatet.
5. Installer hele kjeden og last TLS-tjenesten på nytt.
6. Kontroller utenfra at det nye sertifikatet faktisk leveres.
7. Test den automatiske fornyelsen og ekstern varsling.

En lokal sertifikatfil med ny dato beviser ikke at CDN-et eller webserverprosessen bruker den.

Feil 2: Sertifikatet dekker ikke navnet

Sertifikatet må inneholde det eksakte vertsnavnet i Subject Alternative Name-listen. Vanlige varianter:

• bedrift.no er med, men www.bedrift.no mangler
• nytt underdomene er lagt i DNS, men ikke i plattformen eller sertifikatet
• et wildcard for *.bedrift.no brukes på bedrift.no
• et wildcard brukes på et dypere navn som a.b.bedrift.no
• SNI eller virtuell host sender standardsertifikatet for en annen kunde
• CDN-et kjenner DNS-navnet, men custom domain er ikke aktivert i CDN-konfigurasjonen

Legg nødvendige navn til i plattformen og utsted et sertifikat som dekker dem. Kontroller at hver virtuell host peker til riktig sertifikat. Ikke skjul navnefeilen med en redirect; TLS-kontrollen skjer før nettleseren kan motta redirecten.

Feil 3: Ugyldig eller ufullstendig sertifikatkjede

Serveren skal levere nettstedsertifikatet og nødvendige mellomsertifikater, men normalt ikke en vilkårlig hardkodet rot. En manglende intermediate kan virke på noen enheter som har sertifikatet i cache og feile på andre.

Rett webserveren eller plattformen til å bruke utstederens anbefalte full chain. Kontroller deretter fra en ren klient og med et eksternt testpunkt.

Et selvsignert sertifikat kan kryptere forbindelsen, men en vanlig offentlig nettleser kan ikke etablere tillit til identiteten uten en installert tillitsforankring. Selvsignerte sertifikater kan passe i et kontrollert internt miljø med administrert trust store, men ikke som uvarslet løsning for et offentlig nettsted.

Feil 4: Mixed content

Mixed content oppstår når en HTTPS-side henter en ressurs over HTTP. Moderne nettlesere oppgraderer noen typer automatisk og blokkerer andre. Skript, stilark, rammer og nettverkskall er typiske blokkerte ressurser.

Åpne nettleserkonsollen og rett URL-en ved kilden:

• mal eller CSS
• databasefelt
• bildevariant eller srcset
• font, kart, video eller tredjepartsskript
• API-, webhook- eller skjemamål
• nedlastingslenke

Bruk en eksplisitt https://-adresse eller en korrekt relativ intern URL. Protokollrelative adresser som //eksempel.no/fil.js er ikke et godt moderne reparasjonsmønster; siden skal vite at ressursen krever HTTPS.

MDN beskriver hvilke ressurser nettlesere oppgraderer eller blokkerer som mixed content og anbefaler å levere alle ressurser over HTTPS.

Feil 5: Redirect-løkke etter HTTPS-aktivering

Dette skjer ofte når en proxy mottar HTTPS fra brukeren, men kobler til origin over HTTP. Hvis origin ikke stoler på proxyens protokollinformasjon, kan den sende brukeren tilbake til HTTPS for hver forespørsel.

Kontroller:

• hvilken komponent som skal eie HTTP-til-HTTPS-redirecten
• om applikasjonen forstår den opprinnelige protokollen fra en betrodd proxy
• om både www-redirect og HTTPS-redirect peker mot samme endelige vert
• om CDN-regler, webserver og CMS har overlappende redirects
• om redirecten bevarer sti og ikke går via en gammel adresse

Velg én tydelig hovedregel per lag og fjern overflødige mellomsteg. Ikke stol på klientcache mens dere tester; se hele responskjeden.

Feil 6: HSTS gjør siden helt utilgjengelig

HSTS er laget for å hindre at brukeren omgår en TLS-feil. Nettleseren tilbyr derfor ikke «fortsett» for et HSTS-navn med ugyldig sertifikat.

Den offentlige løsningen er å rette sertifikat, navn, kjede eller serverkonfigurasjon. Å tømme lokal HSTS-tilstand hjelper bare én testklient og løser ikke problemet for kunder.

En kortere eller fjernet HSTS-header virker heller ikke umiddelbart for klienter som ikke kan opprette en gyldig HTTPS-forbindelse og allerede har lagret en lengre policy. MDN forklarer at HSTS gjør TLS-feil til feil brukeren ikke kan omgå .

Feil 7: Ingen felles TLS-versjon eller algoritme

En svært gammel server kan bare tilby utdaterte protokoller. En for aggressiv moderne profil kan på sin side stenge ute en eldre klient virksomheten fortsatt er forpliktet til å støtte.

Kartlegg reelle klientkrav, bruk en vedlikeholdt TLS-profil for webserveren og test relevante enheter. Ikke aktiver gamle protokoller globalt bare for å løse én ukjent feilmelding. Isoler heller et dokumentert legacy-behov dersom det faktisk må støttes.

Hvorfor feiler automatisk fornyelse?

Vanlige årsaker er:

• DNS peker ikke lenger til valideringstjenesten
• port 80 er blokkert for HTTP-01
• proxyen sender /.well-known/acme-challenge/ feil
• DNS-API-nøkkelen for DNS-01 er utløpt eller mangler rettighet
• CAA-posten tillater ikke valgt utsteder
• gammel TXT-post eller treg DNS gir feil svar
• ACME-klienten, timeren eller containeren kjører ikke
• diskplass eller filrettighet hindrer skriving
• rate limit rammes etter gjentatte forsøk
• sertifikatet er fornyet, men tjenesten har ikke lastet det inn

Les den første konkrete feilen før dere prøver på nytt mange ganger. Let’s Encrypt anbefaler kontrollert retry og at alle fornyelsesfeil sendes til ansvarlig administrator .

Verifisering etter retting

• Test alle relevante domenevarianter fra utsiden.
• Kontroller sertifikatnavn, utsteder, gyldighet og full kjede.
• Følg redirecten fra HTTP til endelig HTTPS-URL.
• Åpne nettleserkonsollen og se etter blokkerte ressurser.
• Test skjema, innlogging, betaling, API og nedlastinger.
• Test automatisk fornyelse uten å utstede unødvendige produksjonssertifikater.
• Bekreft ekstern varsling til en overvåket adresse.
• Dokumenter årsak, retting og hva som skal hindre gjentakelse.

Bruk oppsettsguiden for HTTPS på webhotell når løsningen skal bygges riktig fra start, og forklaringen av SSL-sertifikat og TLS for begrepene.

SSL-feil hos en Vymo-hostet nettside

Vymo aktiverer HTTPS for den enkle bedriftsnettsiden vi setter opp og hoster. Hvis denne siden viser en sertifikatfeil, send oss hele adressen, feilkoden og tidspunktet slik at leveransen kan undersøkes.

Vymo har foreløpig ikke et selvbetjent SSL-panel og lover ikke Let’s Encrypt eller automatisk fornyelse som en kundeadministrert standardfunksjon. For nettsteder som hostes andre steder, må sertifikatfeilen rettes hos den plattformen som faktisk leverer TLS.