Frågor och svar om certifikat

Tekniska frågor om certifikatet

Vilket FO-nummer och kundnamn används i punkten GetCertificateRequest?

Här följer ett exempel på denna punkt och svar på CustomerID-punkten:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cer="http://certificates.vero.fi/2017/10/certificateservices">

<soapenv:Header/>

<soapenv:Body>

<cer:GetCertificateRequest>

<Environment>TEST</Environment>

<CustomerId>Artificiellt FO-nummer i meddelandet ”Testavtalet för inkomstregistret har behandlats”</CustomerId>

<!--Optional:-->

<CustomerName>Artificiellt kundnamn i meddelandet ”Testavtalet för inkomstregistret har behandlats”</CustomerName>

<RetrievalId>från certifikattjänsten erhållen RetrivalId</RetrievalId>

</cer:GetCertificateRequest>

</soapenv:Body>

</soapenv:Envelope>

Granskas de värden som ingår i CSR (signaturbegäran för certifikatet), såsom common name? Finns det fastställda begränsningar vad gäller dessa, till exempel ska de uppgifter som ingår i CSR vara de samma som i det ursprungliga certifikatet då ett certifikat förnyas, eller ska dessa uppgifter på något sätt motsvara uppgifterna om det företag som skaffar certifikatet?

CSR används tekniskt sett enbart för att leverera en offentlig nyckel. Dess integritet granskas, men de egentliga datafälten i certifikatet utnyttjas inte. Användning av data i andra sammanhang, såsom för att utreda fel är inte uteslutet, varför det är bra att fylla i relativt korrekta uppgifter.

Vilka är uppgifterna i signaturbegäran för certifikatet?

I det skede då en signaturbegäran för certifikatet (CSR) bildas, begärs uppgifter om den organisation som skaffar certifikatet (Subject). Av dessa uppgifter lönar det sig att i signaturbegäran fylla i följande organisationsuppgifter:

  • Common Name (CN), anteckna det artificiella FO-numret
  • Organization (O), anteckna det tilldelade kundföretagsnamnet
  • Country (C), anteckna FI

I produktionen används företagets egna uppgifter, i testmiljön används de testorganisationsuppgifter som getts till företaget.

Varför får jag ett felmeddelande vid identifieringen? Det är fråga om ett certifikat som har laddats ned. (21.3.2018)

Begäran ser ut att stanna vid kontroll av XML-underskriften. Även materialet kontrolleras, varför det skulle skickas ett felmeddelande för dem också.

Det kan vara bra att ändra uppgifterna i begäran (åtminstone CreatorId och SenderId) så att de motsvarar FO-numret i certifikatet.

Vi har hittat fungerande lösningar för XML-underskrifter enligt den praxis som beskrivs i anvisningen. En lösning har varit att skapa en handläggare för genomförandet av Web Service som genomför XML-underskriften precis innan begäran skickas.

Genomförandet av underskriften:

  • läs det första underordnade elementet av Body i Soap-meddelandet och skapa ett nytt XML-dokument av det
  • skapa en XML-underskrift av det nya dokumentet enligt dokumentationen med den nyckel som förknippas med certifikatet
  • ersätt det första underordnade elementet av Body i Envelope med denna version med underskrift
  • övriga åtgärder som eventuellt krävs av programvarubiblioteket för ersättning av det utgående meddelandet med den underskrivna versionen.

Hur fogas CSR-data till en signNewCertificate-operation?

Den base64-enkodade signaturbegäran (CSR) som finns i CertificateRequest-elementet ska anges utan start- och sluttaggar:

-----BEGIN CERTIFICATE REQUEST-----

base64 enkodad CSR-----

END CERTIFICATE REQUEST-----

Hur sparas ett certifikat som fåtts från en getCertificate-operation i en fil?

Om det certifikat som fås i svarsmeddelandet sparas manuellt i en fil, ska man i den base64-enkodade uppgiften i Certificate-elementet lägga till start- och sluttaggar på den egna raden, på så sätt att certifikatuppgiften lämnar mellan dessa:

-----BEGIN CERTIFICATE-----

base64-enkodat certifikat

-----END CERTIFICATE-----

Varför kommer det ett SSLHandshakeException-undantag (inkomstregistrets och certifikattjänstens gränssnitt) när man använder Web Service-tjänsterna?

Problemet hänger sannolikt ihop med den TLS/SSL-version som kundprogrammet använder och därmed anknutna kryptobibliotek. Inkomstregistrets och certifikattjänstens Web Service-gränssnitt använder ett protokoll enligt TLSv1.2 och kundprogrammet ska använda samma version. Kända problem: 

  1. Java 7 och tidigare versioner → Uppdatera till Java 8 eller senare.
  2. SoapUI OpenSource, version 5.3.0 och tidigare använder en föråldrad version av Java. → Uppdatera SoapUI till version 5.4.0 eller uppdatera/ersätt SoapUI-paketerade Java till version 8.

Vilken är certifikattjänstens adress i miljön för intressentgruppstestningen och vart ska tjänsteanropen skickas?

– Detta tjänsteanrop ska göras med HTTP POST-metoden och dessutom ska följande HTTP-rubriker ställas in (headers)

– Content-Type: text/xml;charset=UTF-8

– SOAPAction: "getCertificate"

  • SOAPAction ska vara action för operationen i fråga och de finns i WSDL-beskrivningen.
    – SOAP-meddelanden kan i princip inte skickas med webbläsaren, åtminstone inte utan tillägg (extensions och plugins), utan man måste använda ett program som kan skicka SOAP-meddelanden.

Vad har SFTP-kanalen för adress? (21.3.2018)

Adressen är 131.207.14.21 och den finns också i domännamnsystemet med namnet sftp-testi.tulorekisteri.fi, produktionens adress kommer att vara sftp.tulorekisteri.fi.

Hur identifierar jag mig i SFTP-kanalen? (3.4.2018)

SFTP-användarnamn är av formen 0ac1ee931da7cf1ce_PW. Användarnamnet skickas till kontaktpersonen för testningen och till den tekniska kontaktpersonen via e-post när den part som genomför testningen har hämtat ett testcertifikat. I SFTP-kanalen identifierar man sig med SSH-autentisering med användarnamnet och en privat nyckel av det nyckelpar som intressentgruppen har använt för att skriva under signaturbegäran för certifikatet (CSR). Något lösenord används alltså inte.

Vilka är de rätta attributen för användningen av Signature-noden? (21.3.2018)

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />

<Reference URI="">

<Transforms>

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />

<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />

</Transforms>

<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />

Ska man skapa en egen offentlig nyckel, en privat nyckel samt en separat PCKS#10-certifikatbegäran för varje kund för skapandet av ett nytt certifikat? Räcker det inte med en gemensam offentlig/privat nyckel samt en fil för PCKS#10-certifikatbegäran för alla kunder? I så fall skulle den överföringskod och det engångslösenord som skickats till kunderna räcka till identifiering vid skapandet av en ny hämtningskod för certifikat och XML-underskriften. (21.3.2018)

Om det är fråga om en bokföringsbyrå, kan byrån använda sitt eget certifikat och skapa material och anmäla uppgifter för sina kunder. Om det är fråga om förmedling av material, ska man skapa ett eget nyckelpar och en signaturbegäran för certifikatet för varje kund och skapa certifikat av dessa.

Finns det något konkret exempel/verktyg med vilket man kan skapa ett nyckelpar och en PCKS#10-certifikatfil och foga en offentlig nyckel till den? (21.3.2018)

Vi strävar efter att publicera anvisningar om detta så fort som möjligt.

Vad är bästa sättet att hantera kundernas egna offentliga/privata nycklar och PCKS#10-certifikatfiler? (21.3.2018)

Detta varierar mellan de olika systemen och miljöer, det är svårt att ge några kundspecifika anvisningar. Det kan vara bra att den som administrerar systemet också skapar nyckelparen och signaturbegäran för certifikat och administrerar certifikaten.

Hämtning av certifikat

När certifikat som begärts eller förnyats hämtas med en GetCertificateRequest-begäran, ser det ut som om felkoderna i det mottagna svaret inte omfattar en kod för en situation där begäran om att skapa ett certifikat fortfarande är under behandling. (Bild 2 i den allmänna beskrivningen av certifikattjänsten nämner behandlingstiden). Kommer en felkod såsom ”begäran om certifikat under behandling” att komma för detta?

Detta är ännu under prövning för produktionsmiljön, men för tillfället finns det inte någon separat felkod

Vilken är behandlingstiden vid hämtning av ett begärt eller förnyat certifikat med en GetCertificateRequest-begäran?

I dokumentationen har väntetiden fastställts till 5 minuter, men i praktiken är tiden kortare än 30 sekunder. Ofta är tiden klart kortare.

Varför lyckas inte hämtningen av certifikat?

Hämtningen av certifikat kan misslyckas till exempel på grund av en felaktig hämtningskod (RetrievalId).

Vid ansökan om certifikat måste man beakta att en signaturbegäran (SignNewCertificate) får göras med överföringskoder (TransferId och TransferPassword) bara en gång. Hämtning av certifikat (GetCertificate) kan göras med samma hämtningskod (RetrievalId) flera gånger. På grund av en fördröjning mellan signaturbegäran och hämtningen är det skäl att vänta en stund.

Hur kan jag ändra den tekniska kontaktpersonen? Ska jag skriva ett nytt avtal? (9.4.2018)

Något nytt avtal behövs inte. Den som har skrivit under det ursprungliga avtalet kan meddela förändringen via e-post till adressen YHT_Tulorekisteri_testaus@vero.fi.

Om man inte hinner hämta certifikatet inom de två veckorna, kan man förlänga hämtningstiden? (9.4.2018)

Hämtningstiden kan inte förlängas, men man kan beställa ett nytt certifikat genom ett meddelande med observationsblanketten. 

Det nuvarande testcertifikatet kan inte användas tillsammans med den privata nyckeln. Är det möjligt att radera det nuvarande testcertifikatet och göra en ny certifikatbegäran? (9.4.2018)

Det är inte möjligt att radera testcertifikatet, men man kan beställa ett nytt certifikat och då får man överföringskoder för en ny certifikatbegäran. 

Jag har fått ett e-postmeddelande som innehåller en länk till webbplatsen där jag bör ange min PIN-kod. Jag misstänker att mitt telefonnummer kan ha angetts fel i formatet 420 xxx xxx xxx. Landsnumret till Tjeckien är +420 eller 00420. Jag skickade en anmälan till er via webbplatsen, men jag kunde inte skriva något meddelande. Kan ni korrigera mitt telefonnummer 0042 xxx xxx xxx så att jag kan ta emot PIN-koden? (9.4.2018)

Telefonnumret hade angetts i rätt format, men den utländska operatören hade inte tagit emot det meddelande som skickats, troligen för att meddelandet inte har skickats från ett vanligt telefonnummer utan från en sändningstjänst.

Om ni upptäcker problem med det säkra e-postmeddelandet eller med SMS, kontakta oss med observationsblanketten.

I dokumentationen för Arbetsgivarens separata anmälan finns följande text under punkten Arbetspensionsanstaltens bolagskod: Uppgiften ska vara identisk med de första två tecknen i uppgiften Pensionsarrangemangnummer. Enligt koduppsättningen börjar emellertid en del av arbetspensionsanstalternas koder med 5 tecken. 

Om uppgiften samtidigt ska vara PensionProvldCode enligt koduppsättningen och identisk med de två första tecknen av pensionsarrangemangnummer, hur ska man hantera koderna med 5 tecken? (9.4.2018)

Dokumentationen för arbetsgivarens separata anmälan har inte uppdaterats för denna del. I schemabeskrivningen av anmälan om löneuppgifter beskrivs samma fråga på följande sätt: Uppgiften ska vara identisk med de första två/fem tecknen i uppgiften Pensionsarrangemangnummer. 

Vi kommer att uppdatera texten i följande version av schemabeskrivningen av arbetsgivarens separata anmälan.

Hur får en redovisningsbyrå/en direkt kund/slutkunden engångslösenordet och överföringskoden via det tekniska gränssnittet? Behöver slutkunden alls befullmäktiga redovisningsbyrån? (7.5.2018)

Redovisningsbyrån/slutkunden ingår ett tjänsteavtal om användningen av det tekniska gränssnittet i inkomstregistrets e-tjänst och anger kontaktpersonen för certifikatet.

Kontaktpersonen för certifikatet får ett säkert e-postmeddelande till sin angivna e-postadress och ett SMS med en PIN-kod med vilken hen kan öppna e-postmeddelandet. Överföringskoder (TransferID och TransferPassword) som hänför sig till certifikatbegäran finns i e-postmeddelandet. 

En redovisningsbyrå ska inneha ett giltigt uppdragsavtal och behörighet att agera för sin kund.  

Certifikat och intressentgruppstestning

Vår organisation vill använda flera olika certifikat i intressentgruppstestningen av inkomstregistret. Ska vi ingå ett testavtal för varje certifikat för intressentgruppstestning?

Nej. Varje organisation ingår ett testavtal för intressentgruppstestningen. Om en organisation vet att den behöver flera certifikat för testningen, ska en begäran om detta fogas till det e-postmeddelande med vilket ett undertecknat och inläst testningsavtal och användarvillkoren för testmiljön sänds till Skatteförvaltningens inkomstregisterprojekt. I bilagan ska antalet nödvändiga certifikat och användningsbegränsningarna för certifikaten antecknas. Om olika certifikat har olika tekniska kontaktpersoner, ska också deras uppgifter meddelas.

Om testavtalet redan godkänts eller om testningen redan pågår, kan programvaruföretaget begära flera certifikat med observationsblanketten. Länken till observationsblanketten sänds till den testande organisationen efter behandlingen av testavtalet. En begäran som sänts på observationsblanketten ska omfatta uppgifter om den tekniska kontaktpersonen, den certifikattyp som behövs, det artificiella FO-numret (CustomerID) och det artificiella organisationsnamn som anknyter till FO-numret (CustomerName), vilka tidigare överlämnats till testande organisationen.

Ett programvaruföretag använder två olika programvaror, som var och en har egna förmedlingstjänster. Bägge programvaror kommer att testas, men testningen av programvarorna börjar vid olika tidpunkter och det är nödvändigt att testa det ena certifikatet senare. Ska programvaruföretaget ingå ett testavtal eller två separata avtal? Är det möjligt att få flera certifikat senare?

Programvaruföretaget kan ingå ett avtal och med samma certifikat testa flera programvaror. Om ett programvaruföretag har ett motiverat behov av att använda fler än ett certifikat, kan begäran om det andra certifikatet sändas i ett senare skede med observationsblanketten. Länken till observationsblanketten sänds till den testande organisationen efter behandlingen av testavtalet.

En begäran som sänts på observationsblanketten ska omfatta uppgifter om den tekniska kontaktpersonen, den certifikattyp som behövs, det artificiella FO-numret (CustomerID) och det artificiella organisationsnamn som anknyter till FO-numret (CustomerName), vilka tidigare överlämnats till testande organisationen.

Personalen vid inkomstregisterprojektet behandlar en begäran som sänts med observationsblanketten inom två veckor. Nya överföringskoder sänds till den tekniska kontaktpersonen för hämtning av det andra certifikatet. Överföringskoderna är giltiga i 14 dygn. Det är inte nödvändigt att ingå ett nytt testavtal.

När ett certifikat ansöks i testmiljön, hur länge gäller engångslösenordet för att hämta certifikatet (OTP, TransferPassword)?

De överföringskoder som behövs för att hämta certifikatet är i kraft i 14 dygn.

Vår koncern har flera programvaror som vi behöver testa. Testningen kommer att göras under olika tider och via olika programvaror. Vi behöver med andra ord två certifikat trots att vi är en stor koncern. Hur borde vi förfara? Kan vi ingå separata avtal om intressentgruppstestning för bägge programvaror?

Koncernen ingår ett testavtal. Det är möjligt att skaffa olika certifikat för olika programvaror, om det finns ett motiverat behov för detta. Om certifikaten skaffas innan testningen börjar, ska organisationen på samma gång som testavtalet ingås göra en fritt formulerad begäran och foga det till det e-postmeddelande med vilket det sänder testavtalet och användningsvillkoren för testmiljön till inkomstregisterprojektet. I bilagan ska antalet nödvändiga certifikat och användningsbegränsningarna för certifikaten antecknas. Om olika certifikat har olika tekniska kontaktpersoner, ska också deras uppgifter meddelas.

Om testningen av programvaror inleds under olika tider, ska en begäran om certifikat sändas med observationsblanketten. En begäran som sänts på observationsblanketten ska omfatta uppgifter om den tekniska kontaktpersonen, den certifikattyp som behövs, det artificiella FO-numret (CustomerID) och det artificiella organisationsnamn som anknyter till FO-numret (CustomerName), vilka tidigare överlämnats till testande organisationen.

Ett programvaruföretag kan inte ingå ett produktionsavtal. Ett certifikat för produktionsskedet beviljas för en bokföringsbyrå eller ett företag. Slutkunden kan dock i produktionsskedet besluta vem som kan fungera som teknisk kontaktperson för organisationens räkning och tekniskt sett administrera certifikaten.

Hur testas förnyande av ett certifikat? Ett certifikat gäller i 2 år och det kan förnyas först 60 dygn innan det går ut.  

För tillfället är det inte möjligt att testa förnyande av ett certifikat, men vi försöker utveckla funktionerna på så sätt att också förnyande av ett certifikat kan testas.

När det är möjligt att testa funktioner som gäller certifikatets livscykel, ger inkomstregisterprojektet separat information om detta.

Kan vår tekniska kontaktperson få meddelanden som gäller ansökan om certifikat på engelska?

De meddelanden som gäller certifikattjänsten och sänds till de tekniska kontaktpersonerna är på tre språk (finska, svenska och engelska).

Kommer begäran om stängning av ett certifikat (revoke) att vara föremål för en egen begäran i gränssnittet?

I produktionsskedet görs en begäran om stängning av ett certifikat till inkomstregistermyndigheten under tjänstetid och till helpdesk utanför tjänstetid.

I intressentgruppstestningsskedet görs en begäran om stängning till den organisation som testar inkomstregistret, om det handlar om ett certifikat som beviljats för testning.

Ett programvaruföretag har inget finländskt FO-nummer. Kan det ingå ett testavtal?

Ja. I punkten FO-nummer i testavtal meddelas företagets utländska identifierare.

Ett programvaruföretag vill testa integreringen av reseersättningar i inkomstregistret. Är det nödvändigt att från resehanteringssystemet genomföra ett tekniskt gränssnitt till certifikattjänsten eller är det så att certifikat inte överlämnas för testning på annat sätt än via gränssnittet för certifikattjänsten? (Vid produktionsanvändning hämtar certifikatet av det ena datasystemet för informationsproducent.)

Certifikatet för testningen sänds enbart via certifikattjänstens gränssnitt.

Den privata nyckel som anknyter till certifikatet innehas enbart av den programvara som anknyter till inkomstregistret, varför kunden ska bilda den. Certifikattjänstens gränssnitt är ett Web Service-gränssnitt, varför hämtningen av certifikat kan integreras som en fast del av kundprogrammet eller så kan certifikatet hämtas med separata Web Service-programvaror såsom SoapUI eller Postman.

Vad används FO-numren på PDF-listan till i intressentgruppstestningen, om man inte kan hämta ett certifikat med dem? (7.5.2018)

Till varje organisation som testas skickas 40 FO-nummer och 200 personbeteckningar. Intressentgrupperna kan själva välja hur många löntagare varje betalare med FO-nummer har i löneuppgiftsmaterialet. Också personbeteckningarna kan fritt fogas till FO-numret. Man kan vid behov få fler testkunder från inkomstregisterprojektet. 

https://www.vero.fi/globalassets/tulorekisteri/bilaga1_testanvisning.pdf

Ni kan också anmäla till inkomstregistret ett begränsat antal av era egna testkoder som ni vill lägga till på inkomstregistrets intressentgruppstestning.

https://www.vero.fi/globalassets/tulorekisteri/bilaga-7-anvisning-f%C3%B6r-avidentifiering-av-testmaterialet.pdf

I vårt reseräkningssystem finns det i samma miljö (serverprogram, databas) flera juridiska företag som har sina egna certifikat för produktionen. Vi måste kunna testa en situation där vårt program som skapar material för anmälan om löneuppgifter startar enligt tidsinställningen och hittar det rätta certifikatet för varje företag. Vi vill alltså testa att skapa parallella anmälningar om löneuppgifter från samma databas och samma server för olika företag. 

Vi vill alltså använda FO-numren i PDF-filen i vår testmiljö, hämta ett testcertifikat för vart och ett av dem och skapa material om löneuppgifter till inkomstregistrets testmiljö. Är detta möjligt? (7.5.2018)

Tyvärr kan ni endast använda det artificiella FO-nummer (CustomerID) som skickats till er och det organisationsnamn (CustomerName) som förknippas med det i skapandet av testcertifikat.

Ni kan dock om ni så önskar skapa flera certifikat i denna organisations namn. Ni kan alltså operera med flera certifikat vid behov, dock så att certifikatets innehavare är den organisation som nämnts i meddelandet nedan.

Eftersom antalet testidentifierare är begränsat, kan vi inte ge er fler testcertifikatorganisationer.

Certifikat i produktionen

Kan en kund ha flera certifikat i användning på samma gång? Kunden har flera programvaror i användning.

Kunderna kan ha flera certifikat i användning på samma gång. När produktionsanvändningen börjar kan kunden beställa certifikat för sin organisation från e-tjänsten för inkomstregistret. Det är också möjligt att en kund använder samma certifikat i olika programvaror.

Kan en kund administrera certifikat på inkomstregister.fi-sidorna, till exempel ladda ner en certifikatfil och föra den till en programvara som den väljer själv?

Ett certifikat bildas enligt de tekniska anvisningarna https://www.vero.fi/sv/inkomstregistret/programutvecklare/certifikattj%C3%A4nst/ .

Under produktionen kan kunden i e-tjänsten för inkomstregistret se en lista över de certifikat som är i organisationens användning.

Kan vår tekniska kontaktperson få meddelanden som gäller ansökan om certifikat på engelska?

De meddelanden som gäller certifikattjänsten och sänds till de tekniska kontaktpersonerna är på tre språk (finska, svenska och engelska).

Om programvaruleverantör X skaffar ett eget certifikat, kan alla bokföringsbyråer som använder programvaran därefter använda programvaran X:s certifikat?

Programvaruleverantör X fungerar som programvaruföretag. Varje kund som använder programvaran X, såsom en bokföringsbyrå eller ett företag, ska skaffa ett eget certifikat för produktionsanvändning av inkomstregistret.

Ska varje programvaruföretag som genomför ett tekniskt gränssnitt i inkomstregistret, genomföra ett tekniskt gränssnitt också i certifikattjänsten?

Certifikatet för produktionsskedet ska skaffas av programvaruföretagets kundföretag (en bokföringsbyrå eller ett företag). I praktiken ska man dock i programvaran genomföra en lösning med vilken certifikatet hämtas och sparas för användning av programvaran.

Certifikat och bokföringsbyråer

Ett programvaruföretags kunder utgörs av bokföringsbyråer och dessa sköter de egna kundernas ekonomiförvaltning och löneärenden i löneförvaltningsprogram X. Om bokföringsbyrån för kundföretagets räkning sänder en inkomstregisteranmälan, är det då möjligt att använda programvaran X:s egna certifikat? Behöver bokföringsbyrån själv ha någon form av certifikat i anknytning till programvaran X?

Programvaruleverantör X fungerar som programvaruföretag. Varje bokföringsbyrå som använder programvaran X ska skaffa ett eget certifikat för produktionsskedet. Bokföringsbyråerna behöver följaktligen egna separata certifikat. Företag eller bokföringsbyråer som använder ekonomiförvaltningsprogrammet behöver ett certifikat.

Avtal om inkomstregistret för produktionsskedet ska ingås av bokföringsbyrån. Produktionsavtal kan ingås från och med hösten 2018. Trots att bokföringsbyrån ingår avtalet, kan det dock med avtalet anmäla till exempel en företrädare för programvaruhuset som teknisk kontaktperson, som i så fall får uppgifter för ansökan om certifikat och följaktligen i praktiken hämtar certifikat för bokföringsbyråns räkning.

Hur skaffar man certifikat och hur används de i en bokföringsbyrå?

Exempel

Bokföringsbyrå A, med kunderna:
Kund 1 Ab
Kund 2 Ab
Kund 3 Ab 

Bokföringsbyrå B, med kunderna:
Kund 2 Ab
Kund 4 Ab, vill själv göra materialbeställningar

Vilka av dessa alternativ används
1. Ska varje Kund själv skaffa ett certifikat och överlämna det till Bokföringsbyråns användning?
2. Ska Bokföringsbyrån skaffa ett certifikat för Kundens räkning?
3. Eller har Bokföringsbyrån ett certifikat, som alla Kunder använder?

En prokurist vid bokföringsbyrån ingår ett serviceavtal med inkomstregistret och skaffar ett certifikat.

I samband med ansökan om certifikat är det möjligt att som teknisk kontaktperson utse till exempel en företrädare för programvaruföretaget, som i praktiken sköter hämtningen av certifikat för bokföringsbyrån. Certifikatet kan i praktiken bildas för bokföringsbyrån av den aktör som bokföringsbyråns prokurist antecknat som teknisk kontaktperson.

Vilket är förfarandet för Kund 2 Ab, vars löneärenden sköts av Bokföringsbyrå A och Bokföringsbyrå B?

Bägge bokföringsbyråer har egna certifikat och de sköter ärenden för sina kunders räkning på normalt sätt, enligt överenskommelsen om uträttande av ärenden med Kund 2 Ab.

Vilket är förfarandet för Kund 4 Ab, som själv vill göra materialbeställningar, men vars anmälningar sköts av Bokföringsbyrå B?

Kund 4 Ab kan använda e-tjänsten för att beställa material eller skaffa ett eget certifikat. Bokföringsbyrå B har ett eget certifikat, som används för anmälan.

Behöver bokföringsbyråer och företag som använder löneberäkningsprogram skaffa certifikat? Behöver ett företag eller en bokföringsbyrå befullmäktiga programvaran X att sända material för dess räkning?

Företag och bokföringsbyråer som använder ekonomiförvaltningsprogrammet behöver var och en egna certifikat. Om en bokföringsbyrå sköter ett företags ärenden, behöver bokföringsbyrån ett certifikat, som det använder för att uträtta ärenden för alla sina kunders räkning. Ett företag som är kund hos en bokföringsbyrå behöver med andra ord inte ett eget certifikat, om det inte själv anmäler löner via gränssnittet.

När en bokföringsbyrå förbundit sig till användningsvillkoren för inkomstregistret, kan det anmäla uppgifter via gränssnittet för ett kundföretag som det företräder. Med andra ord behöver det företag eller den bokföringsbyrå som använder ekonomförvaltningsprogrammet ett certifikat.

Suomi.fi-befogenheter behövs inte för att använda det tekniska gränssnittet. Däremot används Suomi.fi-identifiering i e-tjänsten för inkomstregistret och företaget ska ge nödvändiga personer och aktörer Suomi.fi-fullmakter för att sköta ärenden för dess räkning.

Hur ska man förfara om en bokföringsbyrå eller ett företag har flera programvaror, från vilka anmälningar produceras direkt till inkomstregistret (till exempel löneberäknings- och resehanteringsprogram)?

Samma certifikat kan användas i olika programvaror hos samma bokföringsbyrå/kundföretag. Samma certifikat kan användas med olika programvaror vid en bokföringsbyrå eller företag, om samma typ av certifikat lämpar sig för olika programvarors behov. Alternativt kan ett eget certifikat skaffas för varje programvara.

Certifikat och SaaS-tjänsten

En förutsättning för användning av inkomstregistrets gränssnitt är att ett certifikat skaffas antingen för företaget själv eller för bokföringsbyråer eller andra löneadministrationspartner som uträttar ärenden för dess räkning.

Vilket är förfarandet om ett företag köpt lönerelaterade tjänster som en SaaS-tjänst av en programvaruleverantör? Kan det på samma server finnas många företags certifikat för inkomstregistret?

Inkomstregistret tar inte ställning till hur många certifikat som finns på samma server. Med andra ord är inte antalet begränsat.

Också i SaaS-tjänsten skaffar varje företag som anmäler uppgifter ett eget certifikat. Som teknisk kontaktperson för certifikatet är det möjligt att utse en företrädare för SaaS-serviceleverantören, då han eller hon för företagets räkning kan hämta och installera ett certifikat.

Certifikat och molnbaserade produkter

Företag Z har molnbaserade produkter, som används av många slutkunder, exempelvis bokföringsbyråer. Beviljas ett certifikat för
1) den organisation som tekniskt sett sänder uppgifter till inkomstregistret via gränssnittet (=Företag Z) eller 2) för den slutkund som bildar materialet, exempelvis bokföringsbyrån?

Certifikatet för inkomstregistret beviljas för slutkunden. Certifikatet beviljas till bokföringsbyrån, men slutkunden kan utse en företrädare för Företag Z som teknisk kontaktperson för certifikatet, som i sin tur i praktiken kan hämta certifikatet.

Förnyande av certifikat

När ett certifikat förnyas, ersätter det nya certifikatet det gamla genast, eller är det gamla i kraft fram till giltighetsdatumet för det ursprungliga? I dokumentationen står det att ett gammalt borde ersättas, men det nämns inte närmare om det nya certifikatet är ett ersättande eller i praktiken ett helt nytt certifikat. Om ett nytt ersätter ett gammalt certifikat, gäller det från och med att det bildats eller först från och med att det hämtats?

Det tidigare certifikatet lämnar i kraft, fram till dess att det går ut eller en separat begäran görs för att stänga det. Det nya certifikatet är ersättande i det hänseendet att det har samma DN som det tidigare, men själva certifikatet är nytt.

Ska man generera ett nytt nyckelpar? (21.3.2018)

Ja. Med förnyelse av nyckeln vill man minska risken av att nyckeln hamnar i fel händer.

Hur skapar man en XML-underskrift med en privat nyckel? (21.3.2018)

Specifikationerna för XML-underskrifter har publicerats i inkomstregistrets gränssnittsdokumentation.

Gäller de krav som hänför sig till förändringar av specialtecken i praktiken kundens namn (CustomerName), om namnet anges via gränssnittet? Är det så att man inte behöver genomföra någon teckenkonversion t.ex. för överföringskoden (TransferId) och engångslösenordet (TransferPassword)? (21.3.2018)

UTF-8-teckenkodning ska användas i gränssnittets tjänster. Om de uppgifter som skickas har kodats enligt UTF-8, behöver man inga konversioner.

Det gick bra att hämta testcertifikat från tjänsten https://pkiws-testi.vero.fi/2017/10/CertificateServices.wsdl, men vid testning av andra tjänster
https://ws-testi.tulorekisteri.fi/20170526/InvalidationService.svc
https://ws-testi.tulorekisteri.fi/20170526/PayerSummaryReportService.svc
https://ws-testi.tulorekisteri.fi/20170526/StatusService.svc
https://ws-testi.tulorekisteri.fi/20170526/WageReportService.svc
returneras endast http-felet 403 forbidden utan några ytterligare förklaringar, både via webbläsaren eller via koden som ett fullständigt Web Service-anrop. Har andra testare råkat ut för motsvarande problem eller vad kan orsaken vara? Ska något av våra internetprotokoll whitelistas? (13.4.2018)

I testmiljön används det certifikat som hämtats från certifikattjänsten också som ett SSL-certifikat. Med detta certifikat gick det bra att identifiera sig.

Såvitt jag förstår kräver testservrarna inte något separat SSL-certifikat, utan certifikatet krävs först i produktionsbruket och även då skulle felet bli http 401 om certifikatet fattas? (13.4.2018)

På testsidan är autentiseringen av kundcertifikaten på, precis som på produktionssidan. Intressentgruppen ska alltså konfigurera sitt program till att använda certifikat vid autentiseringen.

Att underteckna certifikatfiler

Kan ni förklara med ett konkret exempel vilken certifikattjänst som behövs för underteckningar/hurdan den allmänna underteckningsprocessen är? (21.3.2018)

Underteckningsanvisningen finns i tillämpningsanvisningen för det tekniska gränssnittet. Certifikattjänsten undertecknar svarsmeddelandena från Web Service-tjänsterna med sitt eget certifikat. Kunden eller kundens system kan kontrollera denna underskrift och försäkra sig om att svaret kommer från certifikattjänsten. Att kontrollera underskriften är inte obligatoriskt.

XML-tips för materialbeställningar (21.3.2018)

  • DeliveryDataOwner/ = betalarens kod om en sådan finns tillgänglig. Om betalaren saknar kundnummer och tjänsteleverantören sänder uppgifterna i stället för betalaren, ska tjänsteleverantörens kod anges som DeliveryDataOwner
  • Creator/Sender = det artificiella FO-numret för certifikatet ska anges här
  • DeliveryChannelCode = 1, dvs. distributionskanalen SFTP
  • ValidFrom = datumet kan inte vara tidigare än dagens datum
  • ModifiedTimespanEnd = uppgiften kan inte anges för en stående beställning. Hämtningsintervallet för en stående beställning slutar och hämtningsintervallet för följande beställning börjar vid hämtningstidpunkten
  • QueryDataSchemaVersion = uppgift om de schemaversioner som används (anmälningar om löneuppgifter och arbetsgivarens separata anmälningar):
    • http://www.tulorekisteri.fi/2017/1/WageReportsFromIR
    • http://www.tulorekisteri.fi/2017/1/PayerSummaryReportsFromIR
    • På materialbeställningens XML <QueryDataSchemaVersion>http://www.tulorekisteri.fi/2017/1/WageReportsFromIR</
      QueryDataSchemaVersion>
  • QueryProfile = med materialtyp 306 används profilen xx för arbetsgivarens separata anmälan
  • På beställningar av anmälningar om löneuppgifter (300, 303..) används profilen xx
  • De obligatoriska hämtningsparametrarna för beställningar av materialtyp 303: Lista över betalare, Lista över inkomsttagare
  • Underskriften för Signature-elementet ska skapas med det certifikat som hämtats. SFTP-tjänstens adress är sftp-testi.tulorekisteri.fi.