Ny lösning SITHS PKI

Innehållsförteckning

Bakgrund

Som en del av ny lösning för SITHS pågår just nu projektet NLS PKI. Projektets mål är att migrera befintliga PKI-strukturen från Telia Cygate till Ineras egen drift och förvaltning. Primära syftet med en migrering är att minimera påverkan på befintliga förlitande parter, organisationer som använder SITHS idag.

I och med lanseringen av nya spärrtjänsten kommer några infrastrukturfunktioner inom SITHS att byta IP-adresser.

Vi förbereder även miljöerna för IPv6-adresser. Detta kommer dock att konfigureras i DNS vid ett senare tillfälle.

Kunden behöver därmed göra nedanstående insatser snarast:

Observera att:

  • Alla kunder även ska behålla de gamla brandväggsöppningarna

  • Kunder som även har Sjunet utöver Internet ska behålla den gamla logiken för uppslag av DNS-namn och routing

Fram tills flytten av dessa funktioner äger rum.

Målgrupp

Målgruppen för denna information är förlitande parter, ansvariga utgivare och it-organisationer där i synnerhet ansvariga för nätverk och brandväggar inom respektive organisation.

Det här behöver din organisation göra

I och med lanseringen av nya spärrtjänsten kommer följande infrastruktur funktioner inom SITHS certifikatutfärdare att byta IP-adresser:

  1. Spärrlistor (CRL)

    1. Används för att kontrollera om certifikat är spärrade eller ej mot en lista som innehåller alla spärrade certifikat

  2. Online certifikatstatus protokoll (OCSP)

  3. Länkar för att automatiskt bygga tillit till certifkatkedjan (AIA)

    1. Används främst av Microsoft-system

Detta innebär att system som idag använder något av:

  • SITHS Funktionscertifikat

  • SITHS-certifikat för användare (främst vid autentiseringsmetoden Mutual TLS)

Måste se över följande:

  • Brandväggsöppningar i rätt brandvägg beroende på hur man routar sin trafik

  • Om routingen för trafiken för dessa funktioner ska gå över Internet eller Sjunet (endast kunder med Sjunet)

  • Se till att Source-NAT adressen vid trafik till dessa funktioner matchar det val man gjort om trafiken ska gå över Internet eller Sjunet (endast kunder med Sjunet)

Brandväggsöppningar

Samtliga organisationer måste säkerställa att man har brandväggsöppningar för följande IP-adresser.

Samtliga brandväggsöppningar ska göras för:

  • Protokoll: HTTP

  • Port: 80

  • Riktning: Utgående nätverkstrafik

För kunder som har Sjunet bör man även se över sin logik för DNS-uppslag och routing, se DNS-uppslag och routinglogik för Sjunet

Olika funktioners DNS-namn och Gamla vs. nya IP-adresser

Produktion

  • crl1.siths.se

    • Gammal IPv4: 194.237.208.239

    • Ny IPv4: 82.136.183.246

    • Ny IPv6: 2a01:58:6106:5a01::246 (konfigureras i DNS vid ett senare tillfälle)

  • ocsp1.siths.se

    • Gammal IPv4: 194.237.208.174

    • Ny IPv4: 82.136.183.247

    • Ny IPv6: 2a01:58:6106:5a01::247 (konfigureras i DNS vid ett senare tillfälle)

  • aia.siths.se

    • Gammal IP; 194.237.208.239

    • Ny IPv4: 82.136.183.248

    • Ny IPv6: 2a01:58:6106:5a01::248 (konfigureras i DNS vid ett senare tillfälle)

QA (tidigare SITHS Preprod)

  • crl1pp.siths.se

    • Gammal IP: 194.237.208.238

    • Ny IPv4: 82.136.183.150

    • Ny IPv6: 2a01:58:6106:3a05::150 (konfigureras i DNS vid ett senare tillfälle)

  • ocsp1pp.siths.se

    • Gammal IP: 194.237.208.170

    • Ny IP: 82.136.183.151

    • Ny IPv6: 2a01:58:6106:3a05::151 (konfigureras i DNS vid ett senare tillfälle)

  • aiapp.siths.se

    • Gammal IP: 194.237.208.238

    • Ny IP: 82.136.183.152

    • Ny IPv6: 2a01:58:6106:3a05::152 (konfigureras i DNS vid ett senare tillfälle)

DNS-uppslag och routinglogik för Sjunet

Observera att denna information gäller endast kunder med Sjunetuppkoppling

Schematisk skiss för DNS-uppslag och routinglogik

 

Innan flytt

  1. Organisationens tjänster slår upp ovan funktioners DNS-värden och får olika IP-adresser beroende på om man ställer sin DNS-fråga över Internet eller Sjunet.

  • Ställer man DNS-frågan över Internet får man en Internet IP-adress.

  • Ställer man DNS-frågan över Sjunet får man en Sjunet IP-adress. Exempel på Sjunet-adress: är “crl2.siths.sjunet.org”.

2. Beroende på vilken IP-adress man får enligt ovan tar nätverkstrafiken olika vägar antingen

  • Internet IP-adress --> Trafiken går över Internet

  • Sjunet IP-adress --> Trafiken går över Sjunet.

3. Beroende på vilket nätverk trafiken tar enligt ovan måste organisationen se till att trafiken Source-NAT:as bakom en IP-adress som SITHS-tjänsten förknippar med samma nätverk. Detta för att förhindra asynkron routing.

  • Om trafiken går över Internet måste trafiken Source NAT:as bakom en Internet IP-adress

  • Om trafiken går över Sjunet måste trafiken Source NAT:as bakom en Sjunet IP-adress

Exempel på fel som kan uppstå:
Organisationen skickar trafiken via Sjunet, MEN med en Source-IP som pekar på Internet. Vilket gör att SITHS försöker skicka tillbaka anropet via Internet och svaret når aldrig frågande part.

4. Brandväggsöppningar måste finnas i rätt brandvägg beroende på vilken väg trafiken tar enligt ovan logik för de Gamla IP-adresserna i listan över Brandväggsöppningar

Efter flytt

  1. Organisationens tjänster slår upp ovan funktioners DNS-värden och får SAMMA IP-adresser oavsett om man ställer sin DNS-fråga över Internet eller Sjunet

  2. Respektive IP-adress går att nå BÅDE via Internet och Sjunet

  3. Organisationen måste bestämma OM man vill att trafiken ska gå över Internet eller Sjunet

  • Observera! För organisationer med Sjunetuppkoppling - Det IP-spann som används har tidigare kommunicerats som att det ska trafikeras över Sjunet. Därav måste organisationen med största sannolikhet se till att IP-spannet 82.136.183.0/24 routas över Internet om man INTE villa att trafiken ska gå över Sjunet.

4. Beroende på vilket nätverk trafiken tar enligt ovan beslut måste organisationen se till att trafiken Source-NAT:as bakom en IP-adress som SITHS-tjänsten förknippar med samma nätverk. Detta för att förhindra asynkron routing.

  • Om trafiken går över Internet måste trafiken Source NAT:as bakom en Internet IP-adress

  • Om trafiken går över Sjunet måste trafiken Source NAT:as bakom en Sjunet IP-adress

Exempel på fel som kan uppstå:
Organisationen skickar trafiken via Sjunet, MEN med en Source-IP som pekar på Internet. Vilket gör att SITHS försöker skicka tillbaka anropet via Internet och svaret når aldrig frågande part.

5. Brandväggsöppningar måste finnas i rätt brandvägg beroende på vilken väg trafiken tar enligt ovan logik för de Nya IP-adresserna i listan över Brandväggsöppningar

Tester

Routing

Från den server, klientdator etc. som vill kontrollera ett SITHS-certifikat mha. ovan funktioner kan man göra en trace route för att följa trafiken på väg mot målet

  • Tecken på att trafiken går över Internet

    • Näst sista IP-adressen är: 194.168.212.13

  • Tecken på att trafiken går över Sjunet

    • Näst sista IP-adressen är: 81.89.159.168

Åtkomst och Source-NAT

 

Informationsmöte 2022-10-03

 

Lokala anpassningar

En del organisationer har lokala anpassningar och lokal DNS-infrastruktur och det är därför viktigt att tänka på följande:

Lokal DNS-infrastruktur eller DNS-cahce

Om din organisation har egen DNS-infrastruktur eller använder lokal cache av DNS-information måste ni;

  • Uppdateras informationen minst så ofta som TTL-vädet i central DNS anger (60 minuter) så att spärrinformation och AIA-information kan hämtas från de nya IP-adresserna när DNS pekas om till dessa.

  • Sätta högst 60 minuter TTL på era egna DNS-records.

Hämta via IP-adress

Om din organisation hämtar AIA- eller spärrinformation baserat på IP-adress måste ni;

  • i första hand ändra detta till URL och göra namnuppslag enligt ovan,

  • i andra hand uppdatera IP-adresserna för AIA- och spärrinformation.

Inera rekommenderar att alltid använda DNS för att hämta AIA- och spärrinformation samt att alltid uppdatera loka DNS enligt central TTL.

Namnuppslag i hosts-filer

Om din organisation hämtar AIA- eller spärrinformation baserat information i lokala hosts-filer måste ni;

  • i första hand ändra detta till URL och göra namnuppslag enligt ovan,

  • i andra hand uppdatera IP-adresserna för AIA- och spärrinformation i hosts-filerna.

 

Inera rekommenderar att alltid använda DNS för att hämta AIA- och spärrinformation, att alltid uppdatera loka DNS enligt central TTL samt att låta TTL på lokala poster vara samma som central TTL.

Förändringar av Authority Information Access (AIA)

AIA-tillägget i certifikatet används för att specificera vitala resurser för SITHS. Exempelvis publiceras utfärdarcertifikat under SITHS e-id Root CA v2. I den nuvarande lösningen har dessa utfärdarcertifikat presenterats i PEM-format (base64) vilket inte är i överensstämmelse med standarden RFC-5280. Standarden uttrycker att utfärdarcertifikat ska presenterats i DER-format (binärt) varför en ändring görs av AIA i samband med migreringen. Om det finns tillämpningar som inte följer standarden kan dessa få problem. Vi har ännu inte identifierat något sådant exempel, men utesluter inte att det kan finnas.

 

Vid eventuella problem relaterat till denna förändringar finns här tre förslag på väg fram:

  1. Tillse att leverantörer som inte följer standarden RFC-5280 att anpassar sig till den.

  2. Ändra lokalt i det aktuella systemet, exempelvis genom att ändra hostfilen, så att en temporär AIA används (http://pem.aia.siths.se) där de gamla formaten på utfärdarcertifikaten fortsatt presenteras.

  3. Skapa en lokal cache av AIA-informationen med önskat format på utfärdarcertifikaten. Verktyget openssl kan användas för formatkonvertering av utfärdacertifikat.

 

Alternativ 2 och 3 bör ses som temporära lösningar som kan användas till dess att det aktuella systemet uppdaterats till att följa RFC-5280.

Tänk på att många system cache-lagrar AIA-information lokalt och kanske därför inte direkt kommer att uppvisa några symptom.