Usage of certificates and the key/truststores.

[kukel]

Disclaimer: I'm aware that this is not a complete demo and that features are missing and I read #1, Yet...

I started to create a non-peppol plain SBD(H) based AS2 servlet 'server' based on as2-peppol-server (just removed the UBL/Peppol content checks) and concentrated on receiving messages first to see if AS2-lib was/is compatible with our own AS2 software.

As mentioned, I know and understand that this as2-peppol-server project is an 'example', not finished and should be used as a kick-off. But we have to decide fully start from scratch based on as2-lib and as2-servlet (which already helps a lot), or continue to investigate if the approach that is taken in this server should be extended. Borth have advantages and disadvantages. But several issue seem to be at least part of the core of AS2-Lib and that makes it hard to decide. I encountered serveral issues and will post seperate ones in github. This is the first.

When starting the server, the keystore can be a relative path and seems to initialize APKeyManager and checking for the right 'alias' also from as2-server.properties. When receiving documents for this alias decrypting the message, the APKeyManager does not seem to be used. At least the following error occurs

com.helger.as2lib.cert.CertificateNotFoundException: Type: RECEIVER, Alias: KukelsAS2ID
	at com.helger.as2lib.cert.CertificateFactory.internalGetCertificate(CertificateFactory.java:178) ~[classes/:?]
	at com.helger.as2lib.cert.AbstractCertificateFactory.getCertificate(AbstractCertificateFactory.java:66) ~[classes/:?]
	at com.helger.as2lib.processor.receiver.net.AS2ReceiverHandler.decrypt(AS2ReceiverHandler.java:152) ~[classes/:?]
	at com.helger.as2lib.processor.receiver.net.AS2ReceiverHandler.handleIncomingMessage(AS2ReceiverHandler.java:436) ~[classes/:?]
	at com.helger.as2servlet.AbstractAS2ReceiveXServletHandler.handeIncomingMessage(AbstractAS2ReceiveXServletHandler.java:165) ~[classes/:?]
	at com.helger.as2servlet.AbstractAS2ReceiveXServletHandler.onRequest(AbstractAS2ReceiveXServletHandler.java:201) ~[classes/:?]
	at com.helger.xservlet.AbstractXServlet._invokeHandler(AbstractXServlet.java:337) ~[ph-xservlet-9.0.1.jar:9.0.1]
	at com.helger.xservlet.AbstractXServlet.service(AbstractXServlet.java:515) ~[ph-xservlet-9.0.1.jar:9.0.1]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ~[javax.servlet-api-3.1.0.jar:3.1.0]
	at com.helger.xservlet.AbstractXServlet.service(AbstractXServlet.java:570) ~[ph-xservlet-9.0.1.jar:9.0.1]
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:856) ~[jetty-servlet-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) ~[jetty-servlet-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) ~[jetty-security-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) ~[jetty-servlet-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.Server.handle(Server.java:531) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) ~[jetty-server-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281) ~[jetty-io-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) ~[jetty-io-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) ~[jetty-io-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:319) ~[jetty-util-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:175) ~[jetty-util-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:139) ~[jetty-util-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:754) [jetty-util-9.4.9.v20180320.jar:9.4.9.v20180320]
	at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:672) [jetty-util-9.4.9.v20180320.jar:9.4.9.v20180320]
	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_102]

When debugging, it seems that in CertificatFactory.java

      m_aKeyStore = createNewKeyStore (eKeyStoreType);

is called, and a few lines later

load (getFilename (), getPassword ());

which in turn calls

default void load (@Nonnull final String sFilename, @Nonnull final char [] aPassword) throws OpenAS2Exception
{
  final InputStream aFIS = FileHelper.getInputStream (new File (sFilename));
  load (aFIS, aPassword);
}

In this, the file is read as an file and not from the classpath and returns a null inputStream. The actual load in BouncyCastle does not throw an error when aFIS is null, so the previously empty created m_aKeyStore is used which does not contain any certificates, resulting in the error above when accessed (the 'null' check before in public KeyStore getKeyStore () is useless).

It seems the certificate/keystore usage is either not stable or did not get enough attention

Making the keystore in as2-server.properties absolute an absolute file it does work.

Second and related issue is that for Sending encrypted messages, this same PKCS12 keystore is used and not the APTrustStore or whatever. And the same

protected X509Certificate internalGetCertificate (@Nullable final String sAlias,
                                                @Nullable final ECertificatePartnershipType ePartnershipType) throws OpenAS2Exception

method for the keytore is called which is by default the PKCS12 keystore of the server and not a truststore. So the certificate of the remote party cannot be found by its alias.

[phax]

Okay thanks. Will look at it. I do have an 'empty' web application that uses the as2-servlet to handle incoming requests. I can create a separate project for it but of course it does not provide as many settings and you basically can start from scratch. On the other hand it gives you all the flexibility you want :)
Concerning the above mentioned issues, i will look into them and respond separately

[phax]

Resolved in phax/as2-lib@32d1c20 - so please check with the latest as2-lib 4.2.0 SNAPSHOT version

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.