---
title: Slik holder dere sertifikatet og TLS i orden
description: Hvordan dere sjekker sertifikatet utenfra, hva som faktisk går galt med fornying, og hvilke protokollversjoner som bør være av.
updated: 2026-08-16
minutes: 20
canonical: https://glippen.no/veiledninger/sertifikat-og-tls
author: Erik Nilsen
---

# 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.

> Alle kommandoene under leser. Ingen av dem endrer noe.

## 1. Se hva som faktisk serveres

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

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

**Riktig svar.** En 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.

```sh
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.

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

**Riktig svar.** En 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.

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

**Riktig svar.** En 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.

```sh
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.

## Det som faktisk går galt

- 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.