Simple java client for submission of receipts to the central registry at eet.cz.

It solves following topics:

• Keys and certificates import
• Webservice communication
• Computation of verification codes PKP and BKP
• Signing of requests (WS-Security)
• Validating of responses (WS-Security)

Implementer has to take care of:

• Provide InputStream to a valid pkcs12 keystore with client keys
• Provide InputStream to a I.CA root certificate keystore (see lower)
• Errors handling
• Resubmission, in case of failure

InputStream clientKey = getClass().getResourceAsStream("/keys/01000005.p12");
InputStream serverCertificate = getClass().getResourceAsStream("/keys/qica.der");
EETClient service = EETServiceFactory.getInstance(clientKey, "eet", serverCertificate);
OdpovedType response = service.submitReceipt(
    receipt, // content, receipt data
    CommunicationMode.REAL, // real or test mode
    EndpointType.PLAYGROUND,  // which endpoint should be used
    SubmissionType.FIRST_ATTEMPT // first or repeated submission
);
// process the response, repeat if contains error

Every request has to be signed with a client's key. The key will be provided by EET (see how and where). For the demo application and playground environment, some test keys have been published. Those keys are used in integration tests of this demo app.

The signing itself complies with WS-Security. There is a WSS4JOutInterceptor configured, which handles signing, key embedding, hashing algorithms selection and so one.

SOAP responses are signed by a certificate issued for:

O=Česká republika - Generální finanční ředitelství, CN=Elektronická evidence tržeb - Playground, C=CZ

To be able to validate the signature, the root certificate for the I.CA has to be present. You can download it here or go to https://www.ica.cz/CA-pro-kvalifikovane-sluzby and download the SHA-2 DER variant.

This root certificate has to be provided as the third parameter in the submitReceipt method call.

There is a pretty complicated logic, which decides, when the response is signed. Following table summarizes it:

see the original table from documentation

WSS4JInInterceptor handles response validation. It's configured to verify signature against I.CA root certificate, checks CRL and handles all the obscure cases, where message is deliberately unsigned (see the table above).

The client application should verify, that EET public certificate has not been revoked. To do that, either CRL or OCSP should be used. I.CA is the EET's certificate authority. They provide CRL on https://q.ica.cz/cgi-bin/crl_qpub.cgi?language=cs&snIssuer=10500000 for manual download (captcha is required). I.CA should also provide OCSP, as stated in this news article[2011, czech].

Current implementation of this client is based on CRL Distribution Points provided in the EET certificate itself. They point to:

• https://qcrldp1.ica.cz/qica09.crl
• https://qcrldp2.ica.cz/qica09.crl
• https://qcrldp3.ica.cz/qica09.crl

as stated in the following excerpt from the certificate:

[2]: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
  [DistributionPoint:
     [URIName: https://qcrldp1.ica.cz/qica09.crl]
, DistributionPoint:
     [URIName: https://qcrldp2.ica.cz/qica09.crl]
, DistributionPoint:
     [URIName: https://qcrldp3.ica.cz/qica09.crl]
]]

The client reads the provided certificate (sent along with the response) downloads CRLs and checks the EET certificate validity against them. CLR has to have an update interval configured. The client caches CRL in memory and updates it when needed. See the MerlinWithCRLDistributionPointsExtension implementation for details.

WS-Policy is a specification that allows web services to use XML to advertise their policies (on security, quality of service, etc.) and for web service consumers to specify their policy requirements. (from Wikipedia)

EET WSDL contained ws-policy with security constraints defined till EET interface version 2. This definition has been removed in version 3. Every developer is now required to take care of setting security configuration manually, following official documentation of EET.

For more details see todvora#1. See also diff between versions 2. and 3. of EET WSDL.

Note: It doesn't affect you as an user of this EET client, is important only for a green field implementations of EET webservice consumers.

• Should be the I.CA root certificate downloaded automatically or provided by the implementer? IMHO no, not secure enough.
• Should the I.CA root be added to the default JVM truststore?
• Create demo project, using this client as a dependency
• Detailed logging
• Run integration tests on travis-ci (apparently blocked travis's IP/range to the WS by EET server itself)
• Security review - is everything as correct as possible?
• Configurable logging when used as a client / connector?

If you want to use this library as a dependency in your Maven based project, follow instructions provided on jitpack.io. There is currently no maven central release.

Since EET client has to deal with lots of encryption and security, up-to-date version of Java should be used.

Supported and tested are following versions:

• Oracle JDK 8
• Oracle JDK 7
• OpenJDK 7
• OpenJDK 6

Oracle Java 6 is after it's end-of-life and doesn't provide required TLSv1.1 implementation for secure communication. Thus it's currently not possible to run this EET client on Oracle Java 6!

Print debugging information regarding SSL connection to EET servers:

-ea -Djavax.net.debug=ssl,handshake

To follow latest news about #EET, join us on eet-cz.slack.com.

• https://github.com/ondrejnov/eet (PHP, MIT license)
• https://github.com/novakmi/eetlite (Groovy, MIT license)
• https://github.com/l-ra/openeet (Java, C#, UNIX shell, Apache 2.0 license)
• https://github.com/mirus77/DelphiEET (Delphi, MIT license)
• https://drive.google.com/drive/folders/0B2B4_OfsI25paTB2R0NNM1hqMzg (C#, unknown license)

MIT License

Copyright (c) 2016 Tomas Dvorak

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

(See a human readable explanation of MIT license).