Teknik FAQ

Innehåll:

1 Felsökning
2 Kommunikation

Felsökning

Virtualiseringsplattformen ska returnera felmeddelanden enligt respektive RIV TA-profil som HTTP 500 med SOAP Fault, med felkoder och felsträng. Ni hittar listan över felkoder och felsträngar på RIV Tekniska Anvisningar Tjänsteplattform under kapitel 5 Virtualiseringsplattform, regel #8: Felkoder.

Vid anslutning av nya anropsadresser utför vi även cURL, se mer information kring felkoder här: libcurl - Error Codes

Kommunikation

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

Klient (SKLTPs) certifikatets CA (root) saknas i tjänsteproducentens truststore (Received fatal alert: handshake_failure)
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)
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 ...)
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)
Fel certifikat installerat hos tjänsteproducenten. Troligen har signeringscertifikatet felaktigt installerats på servern istä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 NTjP utan certifikat?

A: Använd t ex openssl för att testa konnektivitet:

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



… kan komma några fel här beroende på att SITHS CA-cert inte finns i lokalt truststore.
Det viktiga är att se CONNECTED ovan och egenskaper för NTjP-certifikatet.

Q: Hur testar jag konnektivitet mot NTjP med certifikat?

A: Använd t ex openssl för att testa konnektivitet:

$ openssl s_client [ -cert <client-cert> -key <private-key> ] -connect qa.esb.ntjp.se:443 -showcerts