Support for 'private' operationalmode?

[tjeb]

Hi,

we have a few parties developing systems to work with or using Oxalis, and some of them do not have PEPPOL (test) certificates yet, or may not have them at all (since they will not be running the access points themselves as a third party). In order to improve the interoperability testing in an early phase it would be very nice to be able to test with a local PKI in a group that has short lines and quick communication.

I have a patch in my fork that adds a third operational mode 'PRIVATE'; this enables a configuration option oxalis.truststore where a local truststore can be set apart from the existing production and test truststores. It can be found in https://github.com/tjeb/oxalis/tree/private_truststore

Would you consider that a useful addition in the mainline? If so, I can make a pull request; the current branch is based on tag oxalis-3.2.0 which is what we are running, but I could clean it up and base it on master as well. Related to that, are there any new releases planned for 3?

[steinarcook]

Release 3.2.0 is the latest, greatest and final version on the 3.x branch.

The current "main" branch is release 4.x, which is where new development will happen.

I am reluctant to allow private certificates as Oxalis is also tightly coupled to the SMP, which also holds copies of the certificates.

I think private certificates would go against the idea behind PEPPOL.

I have copied my colleague Erlend in case he has a different view on this matter.

Having said all this, Oxalis is open source, so I can not and will not deny you from doing whatever you want as long as it is within the provisions of the EUPL.

On 16 June 2016 at 10:45, Jelte notifications@github.com wrote:

Hi,

we have a few parties developing systems to work with or using Oxalis, and some of them do not have PEPPOL (test) certificates yet, or may not have them at all (since they will not be running the access points themselves as a third party). In order to improve the interoperability testing in an early phase it would be very nice to be able to test with a local PKI in a group that has short lines and quick communication.

I have a patch in my fork that adds a third operational mode 'PRIVATE'; this enables a configuration option oxalis.truststore where a local truststore can be set apart from the existing production and test truststores. It can be found in https://github.com/tjeb/oxalis/tree/private_truststore

Would you consider that a useful addition in the mainline? If so, I can make a pull request; the current branch is based on tag oxalis-3.2.0 which is what we are running, but I could clean it up and base it on master as well. Related to that, are there any new releases planned for 3?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/difi/oxalis/issues/255, or mute the thread https://github.com/notifications/unsubscribe/ABDq0QsBV4IkJ-FVjMXvi99FfwJZwn2jks5qMQ0-gaJpZM4I3KAZ .

Steinar Overbeck Cook

[rikribbers]

Maybe private is the wrong choice of words, I agree that private certificates in PEPPOL are against the idea. Imho 'development' mode would be a better choice.

There are companies where a development/private setup where there is full control over the certificate chain is required during integration testing with oxalis. This would require all keystores to be configurable in oxalis.

[steinarcook]

Sounds better :-)

However it needs to be merged with HEAD on the main branch as we are now heading for version 4.0.1

1. nov. 2016 kl. 12.56 skrev Rik Ribbers notifications@github.com:

Maybe private is the wrong choice of words, I agree that private certificates in PEPPOL are against the idea. Imho 'development' mode would be a better choice.

There are companies where a development/private setup where there is full control over the certificate chain is required during integration testing with oxalis. This would require all keystores to be configurable in oxalis.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/difi/oxalis/issues/255#issuecomment-260317231, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDq0RiqEAPaF0-A4su4TYGlff4u0d_zks5q-EyKgaJpZM4I3KAZ.

[rikribbers]

In other words. You want us to provide a pull-request on the 4.0 branch code base?

[steinarcook]

Yes, please :-)

1. nov. 2016 kl. 14.57 skrev Rik Ribbers notifications@github.com:

In other words. You want us to provide a pull-request on the 4.0 branch code base?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/difi/oxalis/issues/255#issuecomment-260340913, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDq0dGxbMczpVSwymnAAqdwJucG4Z57ks5q-GjJgaJpZM4I3KAZ.

[steinarcook]

One more thing; would you kindly elaborate why you need this?

I.e. if the third parties are not going to be an access point, why do they want to run Oxalis?

I suspect you might be looking for some means of communication between the third parties and your access point? If so, we are about to launch the new vefa-srest component, which provides a REST-interface for the third parties.

1. nov. 2016 kl. 14.57 skrev Rik Ribbers notifications@github.com:

In other words. You want us to provide a pull-request on the 4.0 branch code base?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/difi/oxalis/issues/255#issuecomment-260340913, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDq0dGxbMczpVSwymnAAqdwJucG4Z57ks5q-GjJgaJpZM4I3KAZ.

[rikribbers]

I.e. if the third parties are not going to be an access point, why do they want to run Oxalis?

There are parties in our network (the larger companies) where they have an isolated development/test environment (= no internet access) and they want to do tests where they have control over the certificate chain. So they know how their complete system behaves (e.g. sent invoices with invalid certificates). They want to use oxalis as the accesspoint but without the "private_trustore" functionality this is not possible.

It would help to make the keystores configurable, nothing more and nothing less. I will prepare a pull-request, however given the personal time-constraint it might take a few weeks.

vefa-srest component I'm interested to see what this does. Can we use it to collects statistics out of an AP?

[tjeb]

Another use-case is one we used yesterday; we gave a workshop on installing/configuring Oxalis, with the end result being a closed system where people could play around with Oxalis and send each other business documents. For this we had a local SML, a local SMP, and a local certificate authority.

A number of the participants plan to run PEPPOL access points, but none of them are PEPPOL members just yet, so they couldn't bring their own certificates (and I'd probably recommend against the use of those anyway)

[rikribbers]

I have been working on the implementation on the 4.0 branch, things with respect to the trust- and keystore seem to work however I keep running into an mysql error when I try to send the example document

2016-11-18 12:57:51,782 ERROR [eu.peppol.inbound.server.AS2Servlet] [] Internal error occured: Unable to update database for storing NATIVE_EVIDENCE 
java.lang.IllegalStateException: Unable to update database for storing NATIVE_EVIDENCE
   at eu.peppol.persistence.jdbc.MessageRepositoryH2Impl.updateMetadataFor(MessageRepositoryH2Impl.java:406)
   at eu.peppol.persistence.jdbc.MessageRepositoryH2Impl.saveNativeTransportReceipt(MessageRepositoryH2Impl.java:177)
   at eu.peppol.persistence.guice.jdbc.RepositoryConnectionMethodInterceptor.invoke(RepositoryConnectionMethodInterceptor.java:56)
.....
.....
Caused by: java.sql.SQLException: Can't call commit when autocommit=true
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:868)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:864)

The used command:

./example.sh -i 9908:823123123  -fsrc/main/resources/BII04_T10_PEPPOL-v2.0_invoice.xml -r 9908:810418052 -s 9908:810418052 -u http://localhost:8080/oxalis/as2

To get 4.0 version up and running I had to set the property below in the oxalis-global.properties file

oxalis.transmissionbuilder.override=true

tomcat server.xml

<Resource name="jdbc/sr"
auth="Container"
type="javax.sql.DataSource"
maxActive="100"
maxIdle="30"
maxWait="10000"
username="oxalis"
password="oxalis"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/sendregning?autoReconnect=true"
removeAbandoned="true"
removeAbandonedTimeout="60"
logAbandoned="true"
/>

I have the tables in the database. An entry is added to raw_stats and the message tables. But the message is not in the incoming directory.

My best guess is that I don't have the database properly setup...

Could you provide some pointers to what I am doing wrong? Or where to look for the solution?

[rikribbers]

I have been looking at the problem described earlier, this seems unrelated to my solution. I also have issues with the database setup on the HEAD.

EDIT: and what I should have added is that I could receive messages with a "development" trust- and keystore

[tjeb]

Given that Oxalis now derives the operational mode from the certificate, and you can't even override it, I don't think support for more flexible setups for testing or development is on any roadmap. I will close this issue.