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-adressersamt även börja fungera över .

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

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:

...

• 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

Ankare
brandvaggsoppningar brandvaggsoppningar

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

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

Ankare
DNS-uppslag DNS-uppslag

Schematisk skiss för DNS-uppslag och routinglogik

Informationsmöte 2022-10-03

...

...

Ni har möjlighet att testa era brandväggsändringar genom att navigera till någon av nedanstående länkar.

Respektive sida visar vilken miljö och funktion ni har nått, samt information om vilken utgående IP-adress (Source NAT) ni har från ert nätverk.

 Observera Tänk på att ni, vid behov av test, behöver testa åtkomst både från

• Klientnätverk där ni har användarnas datorer

• Servernätverk där ni har servrar som ska kontrollera SITHS-certifikat

TEST

• http://connectivity-test-crl.test.siths.se

• http://connectivity-test-ocsp.test.siths.se

• http://connectivity-test-aia.test.siths.se

QA

• http://connectivity-test-crl1pp.siths.se

• http://connectivity-test-ocsp1pp.siths.se

• http://connectivity-test-aiapp.siths.se

Produktion

• http://connectivity-test-crl1.siths.se

• http://connectivity-test-ocsp1.siths.se

• http://connectivity-test-aia.siths.se

För kunder med Sjunet

Informationen om utgående ip-adress (Source-NAT) hjälpa kunder med Sjunet att avgöra om man har routat trafiken korrekt. Ligger den utgående IP-adressen inom något av följande spann går trafiken sannolikt över Sjunet:

 81.89.144.0/20

• 213.189.96.0/19

• 82.136.128.0/18

...

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.