Felkoder

Generell standard för HTTP-fel tillämpas.

När http 404 ges innebär det att tjänstekonsument inte får kontakt med närmaste tjänstekomponent/tjänsteplattform.

 När HTTP 500 returneras innebär det att tjänsteplattformen nås, men någonstans i komponentkedjan går det snett. 

Se fullständig lista av http-fel på

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Det finns vissa felsituationer som hanteras av Tjänsteplattformens Virtualiseringsplattform och i dessa fall returneras ett VP-fel. Här är felsökningspunkter för de vanligt förekommande VP fel som konsumenter kan få:

VP004 Det finns ingen tjänsteproducent definierad i Tjänstekatalogen som har ett vägval som matchar ReceiverId (logisk adress), Tjänstekontrakt och dagens datum.

1. Är producenten ansluten och har producenten den angivna logiska adressen?
   1. Om inte, beställ enligt rutiner beskrivna för RTP på Vårdgivarguiden
2. Används rätt Logisk Adress?
3. Skicka en fråga till Serviceförvaltningen IT Service desk, se nedan. Ta med hela felmeddelandet för att underlätta felsökning.

VP006 Det finns mer än 1 tjänsteproducent definierad i Tjänstekatalogen som matchar ReceiverId, Tjänstekontrakt och dagens datum. Tyder på att Tjänstekatalogen är felkonfigurerad.

1. Om felet dyker upp vänligen kontakta Serviceförvaltningen IT Service desk, se nedan. Skicka in hela felmeddelandet för att underlätta felsökning

VP007 Det finns ingen behörighet för tjänstekonsument anropar den logiska adressen. Avser behörigheter definierade i Tjänstekatalogen.

1. Har beställning skickats in? Om inte skicka in beställning enligt rutiner beskrivna för RTP på Vårdgivarguiden
2. Används rätt Logisk Adress i anropet?
3. Skicka en fråga till Serviceförvaltningen IT Service desk, se nedan. Ta med hela felmeddelandet för att underlätta felsökning.

VP009 Fel vid kontakt med tjänsteproducenten.

Det finns många möjliga orsaker till att detta fel dyker upp, kontrollera följande punkter:

1. Att brandväggsöppning för tjänsteplattformens ip-adress är utförd hos producenten
2. Att det inte finns några fel i producentens DNS
3. Att producentens server är uppe och fungerar

Om alla ovanstående punkter är kontrollerade utan att felet hittats, vänligen kontakta Serviceförvaltningen IT Service desk, se nedan.

Felanmälan till Serviceförvaltningen IT Service desk

Felanmälan skickas till Serviceförvaltningen IT via deras kontaktformulär. Fyll i det elektroniska formuläret och ange "RTP" i vallista för "vilket system gäller ärendet".

Inkludera så mycket information som möjligt för att underlätta felsökning. Kontrollera att följande är med (om möjligt):

• Hela felmeddelandet
• Tid för anrop
• Konsumentens HSA ID
• Logisk adress
• Tjänstekontrakt
• IP-adress anrop görs från

Ordlista

HTTPS / SSL

Q: Varför får man "javax.net.ssl.SSLHandshakeException" för utgående trafik från tjänsteplattform mot tjänsteproducent

A: Det kan finnas flera anledningar varav de vanligaste är

1. Klient (SKLTPs) certifikatets CA (root) saknas i tjänsteproducentens truststore  (Received fatal alert: handshake_failure)
2. Det saknas ett CA (root) certifikat i klientens (SKLTPs) truststore alternativt en felaktig konfiguration av truststore och den angivna filen finns inte  (sun.security.validator.ValidatorException: No trusted certificate found)
3. Servers namn som angivits i tjänsteproducentens certifikat (CN) stämmer ej överens med namnet eller IP adressen  som angivits i URL:en   (java.security.cert.CertificateException: No name matching ...)
4. Tjänsteproducenten använder sig av GCM (Galois/Counter Mode) ciphers och dessa stöds ej av standard Java security (sun.security.validator.ValidatorException: Certificate chaining error)
   
5. Fel certifikat installerat hos tjänsteproducenten. Troligen har signeringscertifikatet felaktigt installerats på servern instället för autentiseringscertifikatet från SITHS. (KeyUsage does not allow key encipherment)

Använd openssl för att kontrollera tjänsteproducentens certifikat: 

$ openssl s_client [ -cert <client-cert> -key <private-key> ] -connect <producer-host-name>:<port> -showcerts

Q: Varför får man "javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair" för utgående trafik från tjänsteplattform mot tjänsteproducent

A: Java 7 och tidigare versioner stödjer ej Diffie-Hellman (DH) modulus nyckellängd överstigande 1024 bits. Använder tjänsteproducenten certifikat med längre nyckellängd och i synnerhet Apache 2.4.7 eller senare så är detta fel typiskt. Åtgärdas genom att lägga till specifika DH parametrar till tjänsteproducentens certifikat. Se en bit ned på denna sida från Apache (Why do I get handshake failures with Java-based clients when using a certificate with more than 1024 bits?)

Tjänsteproducenten måste lägga till specifika DH parametrar genom att addera följande (enligt RFC 2409) till varje server certifikat (PEM): 

-----BEGIN DH PARAMETERS-----
MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
-----END DH PARAMETERS-----

Java 8 stödjer upp till 2048, se denna artikel.

Q: Hur testar jag konnektivitet mot RTP?

Linux

A1: Säkerställ att anslutning kommer ut från internt nät genom att använda traceroute och testa därefter anslutning med openssl

~$ traceroute -m 10 prod.esb.rtp.sll.se
> 1 10.0.0.1 (10.0.0.1) 2408.495 ms 2.982 ms 1.735 ms
> 2 192.168.1.1 (192.168.1.1) 3.296 ms 3.561 ms 3.622 ms
...
> 6 sto-ste-er1.sto-cr1.bahnhof.net (46.59.112.42) 4.192 ms 4.290 ms 4.241 ms
> 7 sto-cr1.sto-ste-dr1.bahnhof.net (176.10.178.169) 5.145 ms 4.844 ms 5.295 ms

Svaret innehåller flera "hops" för att nå fram - verifiera att anslutningen lämnar det lokala nätverket.

~ $ openssl s_client -tls1 -connect prod.esb.rtp.sll.se:443
> CONNECTED(00000003) > depth=2 /C=SE/O=Inera AB/CN=SITHS Root CA v1 PP
> depth=2 /C=SE/O=Inera AB/CN=SITHS Root CA v1 PP

Svaret kan innehålla felmeddelanden beroende om SITHS CA-cert inte finns med i lokalt truststore.
Det viktiga är att "CONNECTED" samt egenskaper för RTP-certifikatet visas i svaret.

Windows

A2: Säkerställ att anslutning kommer ut från internt nät genom att använda tracert och testa därefter anslutning med telnet

C:\Users\myAccount\>tracert prod.esb.rtp.sll.se
> 1 10.0.0.1 (10.0.0.1) 2408.495 ms 2.982 ms 1.735 ms
> 2 192.168.1.1 (192.168.1.1) 3.296 ms 3.561 ms 3.622 ms
...
> 6 sto-ste-er1.sto-cr1.bahnhof.net (46.59.112.42) 4.192 ms 4.290 ms 4.241 ms
> 7 sto-cr1.sto-ste-dr1.bahnhof.net (176.10.178.169) 5.145 ms 4.844 ms 5.295 ms
Svaret innehåller flera "hops" för att nå fram - verifiera att anslutningen lämnar det lokala nätverket.

C:\Users\myAccount\>telnet prod.esb.rtp.sll.se 443
Anslutningen skall lyckas och inte visa felmeddelande "Could not open connection to the host, on port 443: Connect failed"