Dessa sidor kommer att tas bort 2023-01-01 |
Dokumenthistorik
Version | Datum | Författare | Kommentar |
---|---|---|---|
0.1 |
| Dokument upprättat i Confluence | |
1.0 |
| Första publika versionen | |
1.1 |
| Modifierat och formaterat efter att detta gjorts i Ineras miljöer för Säkerhetstjänster | |
1.2 |
| Lagt till information om att tänket vid nyinstallation kan bli annorlunda |
SITHS-förvaltningen meddelade 2019-04-26 via Nyhetsbrev och Ineras hemsida att man kommer att begära utträde ur Microsoft Trusted Root Program vilket innebär att SITHS funktionscertifikat blir olämpliga att använda för webbsidor.
https://www.inera.se/siths_nyhetsbrev_2019_april_rootcertifikatprogram
Det står dock inte något i detta meddelande om när detta kan komma att ske men när detta får genomslag blir den direkta påföljden att applikationer som använder listan från detta program inte längre kommer att lita på certifikat utgivna av SITHS. Det bör bland annat gälla Microsofts webbläsare Edge och Internet Explorer men även Googles webbläsare Chrome som kommer att varna användarna som besöker webbsidor som presenterar sig med SITHS-certifikat som potentiellt osäkra. Då det inte är känt när i tid detta kommer att hända kan rekommendationen inte bli annat än att hantera detta så snart som möjligt ifall man vill att användarna ska slippa sådana varningar.
Vid ytterligare frågor kring utträdet kontakta SITHS-förvaltningen genom Ineras Kundservice.
Detta betyder att ansvariga för installationer av Lokala Säkerhetstjänster bör byta ut de certifikat som exponeras i en webbläsare om man vill att användarna ska slippa varningar i sin lokala IdP och gränssnitt för t.ex. Spärr- och Loggadministration. Lokala Säkerhetstjänster exponerar flera webbservrar för olika funktioner som var och en presenterar sig med ett certifikat när webbläsaren ansluter. Traditionellt har Lokala Säkerhetstjänster installerats med port-adressering och då har man klarat sig med ett certifikat. Senare versioner har dock haft stöd för installation med standardporten 443 för säker kommunikation och då har det krävts ett cert per webbserver/domän eftersom SITHS aldrig har kunnat beställas som wildcard-cert eller med flera domännamn i certifikatets fält Subject Alternative Name-fält.
De funktioner/domäner/webbservrar som Lokala Säkerhetstjänster startar upp i 443-konfiguration är:
Förändringen gäller alltså alla domäner utom WS-domänen som fortsatt bör presentera ett SITHS-certifikat ifall man har konsumenter som förväntar sig detta (t.ex. NTjP och RTjP). Övriga domäner används i en webbläsare och bör därför bytas ut.
Man skriver i sitt nyhetsbrev att "Inera erbjuder sina kunder att teckna avtal direkt med Telia för att få SSL-certifikat för detta ändamål". Läs om hur beställning sker på SITHS sidor på inera.se under "Beställ SSL-certifikat av Telia". Telia erbjuder s k SAN-certifikat (certifikat med flera domännamn i certifikatets fält Subject Alternative Name-fält). Ifall man väljer en leverantör som inte erbjuder SAN-certifikat måste man beställa nya certifikat som motsvarar det antal SITHS-certifikat man har i dagens installation. Man kan givetvis även använda andra leverantörer av certifikat som t.ex DigiCert (Basic SAN version, vilket den nationella installation kommer nyttja).
Certifikat för flera domäner. | Prislistan i juni 2019 från Telia (ex moms) för certifikat CA: "TeliaSonera Root CA v1" |
En sak att komma ihåg är att standardkonfigurationen för Lokala Säkerhetstjänster är att använda grunddomänens certifikat (med id:t app under Nyckelhantering) som systemidentitet för att presentera sig när tjänsten själv ropar på externa tjänster som HSA, Personuppgiftstjänsten och Nationell Spärreplikering (direkt eller via NTjP/RTjP). Lokala Säkerhetstjänster måste fortfarande använda ett SITHS-certifikat för denna kommunikation och dessutom så är befintligt app-certifikat upplagt för åtkomsträttigheter i de externa tjänsterna. Byter man ut app-certifikatet så måste man därför även konfigurera Lokala Säkerhetstjänster att använda en annan nyckelgrupp för extern kommunikation. Nedan så kopierar vi konfigurationen för dagens app-certifikat till ett nytt id som vi kallar system och konfigurerar sedan tjänsten att använda det nya id:t som systemidentitet. På så sätt bibehålls systemidentiteten efter det att man ut byter app-certifikatet som ska presenteras för webbläsare.
På samma sätt som att systemet är konfigurerat för att använda app-certifikatet vid kommunikation med andra system så är IdP och SP konfigurerad att använda certifikaten med id idp respektive app för signering av request och response under autentiseringen. Det finns inget krav på att signering ska ske med ett SITHS-certifikat men att byta certifikat för signering medför vissa konsekvenser:
SP:ns certifikat för signering kan konfigureras till att vara det system-certifikat vi kopierat och beskrivit så att systemet signerar sina requests till IdP:n med samma certifikat som tidigare. Det skulle heller inte vara någon stor operation att använda det nya app-certifikatet till signering och byta ut SP-metadata i IdP:n alternativt välja WS-certifikatet så att det fortsätter signeras med ett SITHS-certifikat.
IdP:ns certifikat för signering däremot kan det vara en större operation att byta ut ifall man har flera SP:ar anslutna. Därför kan man skapa en kopia av även denna certifikatskonfiguration och kalla t.ex. idpsystem som man konfigurerar IdP:n att använda. Då har man i och för sig ännu ett SITHS-certifikat att hålla uppdaterat så om man inte kan eller byta signeringscertifikat för IdP gör man kanske en kopia av befintlig certifikatskonfiguration inledningsvis och planerar ett senare certifikatsbyte mer noggrant med anslutna SP:ar.
I instruktionerna nedan så kopieras konfiguration så att ingen metadata behöver bytas ut men det är upp till den ansvarige för installationen av Lokala Säkerhetstjänster som avgör hur detta skall sättas upp.
Vid en nyinstallation av Lokala Säkerhetstjänster kan tänket kring certifikatsuppsättning bli lite annorlunda (se sidorna för Lokala Säkerhetstjänster 2.17).
Grundkonfigurationen av Säkerhetstjänster har inte tagit höjd för att arbeta med olika utgivare på certifikaten som används för presentation och certifikatsanvändning vid externa anrop. Därför blir förändringarna ganska omfattande och innebär:
Editera de nyskapade filerna så att id:n nu överensstämmer med de gamla. Som ovan tittar vi på attributen pid och name.
När det är gjort byter vi det slumpade fil namnet till det gamla filnamnet (1559732051645-0.xml till app.xml)
Före | Efter |
---|---|
| : |
|
|
|
|
Nu ska vi ha följande läge:
Gå till katalogen /share/Sakerhetstjanst2.17/local/config/com.logica.se.iac.http.https.server.factory/
Kopiera app.xml till en fil som heter proxy.xml
Exempel:
sudo cp app.xml proxy.xml
Sätt ägare och rättigheter:
Exempel:
sudo chown ine-sak:ine-sak proxy.xml
sudo chmod g+w proxy.xml
Editera proxy.xml :
Byt namn på pid och attributet httpServiceId till proxy
Byt bindPort till 8449
Byt identityName till system
Byt httpServiceId till proxy
Detta attribut saknas möjligen. Lägg till det i sådana fall som i kodrutan nedan.
<Attribute type="String" key="httpServiceId"> <Value>proxy</Value> </Attribute> |
Nedan listas förslag på kontroller för att se att systemet fungerar som tänkt efter certifikatsbytet:
Om något går fel så ersätter man konfigurationskatalogen som man gjorde en backup av ovan och startar om alla noder.
Exempel
cd /share/Sakerhetstjanst2.17/local/
sudo mv config config_modified
sudo cp -R /var/tmp/certbyte/config .
sudo service sak_server restart (alla noder)