1 Användning av mTLS mot NTjP
- 1.1 Inledning
- 1.2 Vad ni behöver göra
- 1.3 Vad resultatet blir
- 1.4 Teknisk beskrivning
  - 1.4.1 Varför krävs mTLS i NTjP?
  - 1.4.2 Vad mTLS innebär
  - 1.4.3 Så fungerar valideringen i mTLS
  - 1.4.4 Certifikatens livscykel
- 1.5 Steg för aktivering och verifiering
  - 1.5.1 Steg 1: Aktivera mTLS i servern
  - 1.5.2 Steg 2: Lägg till vår CA i truststore
  - 1.5.3 Steg 3: Verifiera att mTLS fungerar
    - 1.5.3.1 Test med OpenSSL
    - 1.5.3.2 Test med curl
- 1.6 Felsökningsguide
  - 1.6.1 Nätverksproblem/brandväggsregler
  - 1.6.2 Problem med certifikatet
  - 1.6.3 Inkompatibla TLS-versioner
  - 1.6.4 Inkompatibla krypteringssviter
  - 1.6.5 Systemklockan är felaktig
  - 1.6.6 Problem med testklienten
- 1.7 Sammanfattning

Användning av mTLS mot NTjP

Inledning

För att ni skall kunna anslutas som producent i NTjP behöver ni aktivera mTLS (mutual TLS) i er webserver. Det innebär att både producenten (servern) och konsumenten (klienten) identifierar sig med certifikat (i vanliga TLS är det endast servern som har certifikat).

Vad ni behöver göra

Aktivera mTLS i er server.
Lägg till vår CA (d.v.s. SITHS) så att vårt certifikat accepteras.
Verifiera konfigurationen genom att testa anslutning med och utan certifikat.

Vad resultatet blir

Utan klientcertifikat → anslutningen blockeras.
Med klientcertifikat → anslutningen fungerar som avsett.

När detta är klart kan vi tillsammans göra ett gemensamt test för att bekräfta att allt fungerar.

Teknisk beskrivning

Varför krävs mTLS i NTjP?

mTLS används för att säkerställa att endast behöriga producenter (servrar) och konsumenter (klienter) kan ansluta till tjänsterna. Producenten identifieras som vanligt via sitt certifikat, och konsumenten måste också styrka sin identitet med ett giltigt certifikat från SITHS.

Vad mTLS innebär

Vid en vanlig TLS-anslutning presenterar endast servern sitt certifikat.
Vid mTLS skickar både servern och klienten certifikat.
Webservern måste vara konfigurerad så att den begär klientcertifikat och dessutom kontrollerar att certifikatet är utfärdat av en betrodd CA.
För att detta ska fungera behöver ni lägga till vår CA i er serverkonfigurations truststore för klientcertifikat.

Så fungerar valideringen i mTLS

Vid mTLS sker först en validering av producentens (serverns) certifikat av konsumenten (klienten), därefter validerar producenten klientens certifikat. Båda stegen måste lyckas innan någon HTTP-trafik kan ske – annars avbryts anslutningen direkt utan HTTP-kod. Det är alltid endast fqdn (fully qualified domain name) i adressen (https://<fqdn>:<port>/<path>) som matchas mot certifikatet, aldrig port eller path.

Klient (konsument) → Server (producent)
1. Producenten skickar sitt certifikat.
2. Konsumenten kontrollerar CA, giltighet och fqdn.
3. Vid fel → anslutningen avbryts direkt (ingen HTTP).
Server (producent) → Klient (konsument)
1. Producenten begär klientcertifikat.
2. Konsumenten skickar sitt certifikat och bevisar ägarskap.
3. Producenten kontrollerar CA och giltighet.
4. Vid fel → anslutningen avbryts direkt (ingen HTTP).
HTTP börjar först när båda certifikat är godkända
1. Först då kan man få svar som 200 OK, 401 Unauthorized, 403 Forbidden eller 5xx Server Error.

Certifikatens livscykel

För att följa beslut inom CA/Browser Forum arbetar vi successivt mot kortare giltighetstider på certifikaten. Idag ligger giltighetstiden på upp till 730 dagar, men målet är att nå 47 dagar år 2029. Vi planerar att successivt korta ner giltighetstiderna även om vi inte nödvändigtvis kommer att följa CA/Browser Forums schema exakt. Eftersom vi redan idag byter certifikat regelbundet avråder vi från att bygga validering baserad på tillfälliga och föränderliga värden, som exempelvis thumbprint. Sådana kontroller motverkar automatisering och leder till mycket extra manuellt arbete när certifikatens livscykel blir kortare. Istället rekommenderar vi att ni använder stabila attribut, som till exempel HSA-ID (som vi inkluderar i subject-fältet), för att identifiera klientcertifikat.

Steg för aktivering och verifiering

Steg 1: Aktivera mTLS i servern

I er serverplattform (t.ex. Tomcat, Nginx, Apache HTTP eller motsvarande) behöver ni aktivera inställningen för klientcertifikat.
Exempel på inställningar:

Tomcat: clientAuth="true"
Nginx: ssl_verify_client on;
Apache HTTP: SSLVerifyClient require

Steg 2: Lägg till vår CA i truststore

För att er server (producent) ska kunna lita på våra klientcertifikat, måste ni lägga till vår CA i er truststore. Detta görs på samma sätt som när ni konfigurerade ert eget servercertifikat. Om vår CA är samma som ni redan använder för era servercertifikat behöver ni bara säkerställa att den är korrekt installerad.

Steg 3: Verifiera att mTLS fungerar

Test med OpenSSL

Utan klientcertifikat (ska misslyckas):
openssl s_client -connect ertservernamn:443
→ Anslutningen ska avbrytas med “handshake failure”.
Med klientcertifikat (ska lyckas):
openssl s_client -connect ertservernamn:443 -cert client.crt -key client.key -CAfile ca.crt
→ Output ska visa: Verify return code: 0 (ok).

Test med curl

Utan klientcertifikat (ska misslyckas):
curl -vk https://ertservernamn/
→ Borde ge TLS-fel (t.ex. “SSL connect error”).
Med klientcertifikat (ska lyckas):
curl -vk https://ertservernamn/ --cert client.crt --key client.key --cacert ca.crt
→ Borde ge ett korrekt HTTP-svar från tjänsten.

Felsökningsguide

Denna felsökningsguide är avsedd som en vägledning för er organisations driftsleverantör. All felsökning och åtgärdande av problem som beskrivs nedan måste utföras och verifieras av er egen tekniska personal eller driftsleverantör.

Denna guide täcker de vanligaste och mest generella problemen. För specifika problem relaterade till er applikation eller miljö, konsultera er driftsleverantörs tekniska dokumentation eller kontakta dem direkt.

Kodexemplen är skrivna i PowerShell och behöver justeras något för t ex Bash. Exemplen förutsätter att variabeln $server är satt till domännamnet (FQDN) för er tjänsteproducent och $port är satt till portnumret.

Nätverksproblem/brandväggsregler

Kontrollera:

Nätverksanslutning och portar
DNS-uppslagning
Routing och nätverkssegmentering
Om ni använder proxy, att den är korrekt konfigurerad för HTTPS.

Problem med certifikatet

Kontrollera att servercertifikatet är signerat av rätt Certificate Authority. Kontrollera att serverns CA-certifikat finns installerat korrekt.

openssl x509 -in ca.crt -noout -issuer
openssl verify -CAfile ca.crt server.crt

Kontrollera certifikatets giltighetstid.

echo Q | openssl s_client -connect ${server}:${port} -servername $server 2>nul | openssl x509 -noout -dates

Kontrollera att servernamnet matchar certifikatets Common Name eller Subject Alternative Name.

echo Q | openssl s_client -connect ${server}:${port} -servername $server 2>nul | openssl x509 -noout -subject -ext subjectAltName

Inkompatibla TLS-versioner

Kontrollera vilka TLS-versioner servern stödjer. Servern måste stödja någon av TLSv1.3 eller TLSv1.2. Den bör inte stödja äldre protokollversioner.

Kontrollera stöd för TLSv1.3:

echo Q | openssl s_client -connect ${server}:${port} -servername $server -cert client.crt -key client.key -CAfile ca.crt -tls1_3

Kontrollera stöd för TLSv1.2:

echo Q | openssl s_client -connect ${server}:${port} -servername $server -cert client.crt -key client.key -CAfile ca.crt -tls1_2

Gå igenom alla protokoll:

foreach ($v in @('ssl3','tls1','tls1_1','tls1_2','tls1_3')) {
  $output = echo Q | openssl s_client -connect ${server}:${port} -servername $server -cert client.crt -key client.key -CAfile ca.crt -$v 2>&1
  if ($output -match "Cipher\s+:") {
    Write-Host "$v : STÖDS" -ForegroundColor Green
  } else {
    Write-Host "$v : STÖDS EJ" -ForegroundColor Red
  }
}

Inkompatibla krypteringssviter

Testa en specifik krypteringssvit för TLSv1.3:

echo Q | openssl s_client -connect ${server}:${port} -servername $server -tls1_3 -ciphersuites TLS_AES_256_GCM_SHA384 -cert client.crt -key client.key -CAfile ca.crt

Testa en specifik krypteringssvit för TLSv1.2:

echo Q | openssl s_client -connect ${server}:${port} -servername $server -tls1_2 -cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 -cert client.crt -key client.key -CAfile ca.crt

Gå igenom alla krypteringssviter:

$ciphers = @{
    tls1_2 = (& openssl ciphers 'ALL:!aNULL:!eNULL' ) -split ':';
    tls1_3 = @('TLS_AES_256_GCM_SHA384', 'TLS_CHACHA20_POLY1305_SHA256', 'TLS_AES_128_GCM_SHA256', 'TLS_AES_128_CCM_SHA256', 'TLS_AES_128_CCM_8_SHA256')
}
foreach ($proto in $ciphers.Keys) {
  $cipherParam = if ($proto -eq 'tls1_3') { '-ciphersuites' } else { '-cipher' }
  foreach ($c in $ciphers.$proto) {
    echo Q | & openssl s_client -connect ${server}:${port} -servername $server -$proto $cipherParam $c -cert client.crt -key client.key -CAfile ca.crt 2>&1 1>nul
    if ($LASTEXITCODE -eq 0) {
      Write-Host "$proto OK: $c"
    }
  }
}

Systemklockan är felaktig

Kontrollera serverns systemtid. Synkronisera systemklockan med NTP.

Problem med testklienten

Kontrollera att ni använder korrekt endpoint.

Kontrollera att klientcertifikatet faktiskt inkluderas i TLS-handskningen.

Kontrollera att klientcertifikatet är signerat av rätt Certificate Authority.

openssl x509 -in ca.crt -noout -issuer
openssl verify -CAfile ca.crt client.crt