Problemer med bruk av klienten på java 1.6.x
Closed this issue · 9 comments
Har et problem med å bruke meldingsformidlerklienten på java 1.6.X. Det fungerer utmerket med java 1.7. Av diverse årsaker er vi avhengig av å kunne benytte 1.6.x.
Får denne feilmeldingen ved bruk av 1.6.X
no.difi.sdp.client.domain.exceptions.KonfigurasjonException: Kunne ikke initialisere xml-signering
at no.difi.sdp.client.asice.signature.CreateSignature.(CreateSignature.java:97)
at no.difi.sdp.client.asice.CreateASiCE.(CreateASiCE.java:49)
at no.difi.sdp.client.internal.CreateDokumentpakke.(CreateDokumentpakke.java:35)
at no.difi.sdp.client.internal.EbmsForsendelseBuilder.(EbmsForsendelseBuilder.java:38)
at no.difi.sdp.client.SikkerDigitalPostKlient.(SikkerDigitalPostKlient.java:50)
at no.si.sdp.MeldingsformidlerClient.(MeldingsformidlerClient.java:31)
at no.si.sdp.MeldingsformidlerClient.main(MeldingsformidlerClient.java:39)
Caused by: java.security.NoSuchAlgorithmException: http://www.w3.org/2006/12/xml-c14n11 algorithm and DOM mechanism not available
at javax.xml.crypto.dsig.TransformService.getInstance(TransformService.java:153)
at org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory.newCanonicalizationMethod(DOMXMLSignatureFactory.java:253)
at no.difi.sdp.client.asice.signature.CreateSignature.(CreateSignature.java:93)
... 6 more
Exception in thread "main" java.lang.RuntimeException: Kunne ikke initiere keystore! Kunne ikke initialisere xml-signering
at no.si.sdp.MeldingsformidlerClient.(MeldingsformidlerClient.java:34)
at no.si.sdp.MeldingsformidlerClient.main(MeldingsformidlerClient.java:39)
Jeg har begynt å se litt på dette, og det tyder jo på at http://www.w3.org/2006/12/xml-c14n11
algoritmen ikke støttes ut av boksen på Java 6. Jeg vet at vi også støtte på problemer med dette i.f.m. POCing av .NET-klient.
I krav 6.2.2 [1] står det i kommentar at "Skal være http://www.w3.org/2006/12/xml-c14n11
". Er det noen spesiell grunn til dette? ETSI-spec'en legger opp til ulike alternativer, bl.a. http://www.w3.org/TR/2001/REC-xml-c14n-20010315
, som også er angitt i kommentaren til krav 6.2.4. http://www.w3.org/TR/2001/REC-xml-c14n-20010315
nevnes som krav i JCA Standard Algorithm Name Documentation for Java SE 6 [3], mens http://www.w3.org/2006/12/xml-c14n11
er ikke nevnt, noe som heller ikke er tilfelle i tilsvarende dokument for Java 7.
Kan kommentar i Krav 6.2.2 endres til "Skal være http://www.w3.org/TR/2001/REC-xml-c14n-20010315"?
@eoftedal, kom gjerne med ev. utfyllende kommentarer.
[1] http://begrep.difi.no/SikkerDigitalPost/1.0.2/forretningslag/Sikkerhet/
[2] http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf
[3] http://docs.oracle.com/javase/6/docs/technotes/guides/security/StandardNames.html#algspec
Det finnes en beskrivelse av forskjellene her her: http://www.w3.org/standards/techs/xmlc14n
Så vidt jeg skjønner er ikke dette noe som normalt vil berøre oss.
Min tolkning av etsy standardens 6.2.2 er også at man kan velge en av de tre øverste.
@ogrinde Har du noen synspunkter?
Det var ingen sterke grunner for den valgte algoritmen, og bakgrunn for å velge en algoritme var for å gjøre valget enkelt for avsendere.
Foreslår at postkassene støtter alle algoritmene (er konform med profilen), og at vi enten velger en annen algoritme for avsendere, eller lar avsendere velge mellom flere algoritmer.
Hvilke/hvilken algoritme bør støttes for å gjøre det enkelt på de fleste platformer?
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 ser ut til å ha bred støtte
@aberner Henger denne bare på å ta en avgjørelse på om vi kan bytte til 1.0 fra 1.1 (og eventuell endring i klientbiblioteket)? Slik jeg forstår er det ingen funksjonelle behov for hvorfor vi krever 1.1? Takk.
Se forslag til løsning beskrevet her: difi/begrep-SikkerDigitalPost#143
Vi ønsker at klientbiblioteket i utgangspunktet fortsatt bruker: http://www.w3.org/2006/12/xml-c14n11
men at det gis en mulighet for de som bruker java 1.6 å override denne konfigurasjonen slik at de kan bruke: http://www.w3.org/TR/2001/REC-xml-c14n-20010315
@aberner I første omgang har vi bare released en versjon som bruker 1.0. Dette for å få en versjon i hendene til SI så fort som mulig slik at de kan komme videre.
løsningsforslaget beskrevet her: difi/begrep-SikkerDigitalPost#143 blir muligens endret så det at klienten er dumpet ned til versjon 1.0 kan være godt nok. venter på at #143 blir avklart.
Dette kortet har ingen utestående oppgaver. Lukker saken.