Sertifikat og TLS

Slik holder dere sertifikatet og TLS i orden

Sertifikatet er sjelden feil oppsatt fra starten. Det er fornyingen som ryker, og den ryker stille: alt virker helt til dagen det ikke gjør det, og da virker ingenting.

Et utløpt sertifikat stopper hele nettstedet og alt som snakker med API-et deres. Det er en av de få feilene som tar ned driften helt uten at noen har angrepet noe.

6 steg · omtrent 20 minutter · oppdatert · skrevet av Erik Nilsen

Framgangsmåte

  1. Se hva som faktisk serveres

    Hent sertifikatet slik en nettleser gjør, og se på utstederen, navnene det gjelder for og datoene.

    echo | openssl s_client -connect example.no:443 -servername example.no 2>/dev/null \
      | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

    Riktig svarEn utsteder dere kjenner igjen, en notAfter-dato et stykke fram i tid, og at domenet står i subjectAltName. Mangler domenet der, får besøkende en advarsel selv om sertifikatet er gyldig.

  2. Sjekk at kjeden er komplett

    Serveren skal sende mellomsertifikatene sammen med sitt eget. Gjør den ikke det, virker nettstedet i de fleste nettlesere, som har dem lagret fra før, og feiler i alt annet.

    Det som feiler er som regel API-kall fra andre systemer, ikke folk. Derfor blir det oppdaget sent, av en integrasjon som plutselig stoppet.

    echo | openssl s_client -connect example.no:443 -servername example.no 2>&1 \
      | grep -E 'Verify return code|verify error'

    Riktig svar"Verify return code: 0 (ok)". Alt annet er verdt å se på.

  3. Slå av protokollversjonene som ikke skal være der

    TLS 1.0 og 1.1 er utdaterte og bør være av. TLS 1.2 og 1.3 er det som skal stå igjen.

    Kommandoen under prøver å koble til med TLS 1.0 og forteller om serveren godtar det.

    openssl s_client -connect example.no:443 -tls1 2>&1 | grep -E 'Protocol|alert|failure'

    Riktig svarEn feil eller en avvist forbindelse betyr at TLS 1.0 er av, som er riktig. Kommer det gjennom, står den fortsatt åpen.

    Pass påSjekk hvem som faktisk kobler til før dere slår av noe. Gamle betalingsterminaler og enkelte integrasjoner henger etter, og de slutter å virke uten forvarsel.

  4. Få fornyingen til å varsle når den svikter

    Automatisk fornying er normalen nå, og det gode med den er at ingen trenger å huske noe. Det dårlige er det samme: når den slutter å virke, er det ingen som legger merke til det før sertifikatet er ute.

    Sett opp en overvåking som sier fra på tid, ikke på utløp. Får dere først beskjed når det er utløpt, er det allerede nede.

    Pass påFornying feiler oftest fordi valideringen ikke lenger kommer gjennom: en omdirigering ble lagt inn, en brannmurregel ble strammet, eller domenet ble flyttet bak en ny proxy. Alt sammen er endringer noen gjorde med god grunn, uten å vite hva de rørte.

  5. Se hvilke sertifikater som er utstedt for domenet deres

    Alle sertifikater logges offentlig i Certificate Transparency. Det betyr at dere kan se hva som er utstedt for domenet deres, også det dere ikke visste om.

    Det er nyttig av to grunner: dere finner gamle testmiljøer og underdomener ingen husker, og dere ser om noen har fått utstedt et sertifikat de ikke skulle hatt.

    curl -s 'https://crt.sh/?q=%25.example.no&output=json' | head -c 2000

    Riktig svarEn liste med navn og datoer. Se etter navn dere ikke kjenner igjen, og etter miljøer som skulle vært slått av for lenge siden.

  6. Legg til en CAA-post

    En CAA-post sier hvilke sertifikatutstedere som har lov til å utstede for domenet deres. Uten den kan hvem som helst av dem gjøre det, forutsatt at de klarer valideringen.

    Det er en linje i DNS og tar minutter.

    dig +short CAA example.no

    Riktig svarÉn eller flere linjer med "issue" og navnet på utstederen dere bruker. Kommer det ingenting, finnes det ingen begrensning.

Feil

Det som faktisk går galt

Ikke de teoretiske feilene. Disse er de vi finner igjen og igjen.

  • Overvåking som varsler på utløp i stedet for i god tid før. Da er beskjeden en hendelse, ikke et varsel.
  • Sertifikatet fornyet på webserveren, men ikke på lastbalansereren, API-et eller e-postserveren som bruker det samme.
  • Manglende mellomsertifikater. Virker i nettleser, feiler i integrasjoner, og blir derfor oppdaget av feil folk på feil tidspunkt.
  • Et wildcard-sertifikat brukt overalt, inkludert på systemer dere ikke lenger kontrollerer.
  • Gamle protokollversjoner slått av uten å sjekke hvem som brukte dem.

Sjekk

Vil dere se om det virket

Den gratis sjekken leser dette utenfra sammen med resten av det som er synlig, og sier hva som fortsatt står igjen. Ingen innlogging, ingen e-postadresse.