Subject Re: [Firebird-Java] Jaybird 3.0.5 FBXADataSource
Author Mark Rotteveel
On 2019-08-15 22:16, Sascha Horn s.horn@... [Firebird-Java] wrote:
>> Was the code using DriverManager run with the same JBoss instance as
>> the
>> one using FBXADataSource? Or did you run it on a different machine
>> or
>> Java installation, or with a different security policy?
>
> No, the DriverManager code is used as standalone application.
>
> It is possible that this code is executed in an other javavm. i will
> check this tomorrow.

It is also possible that it is the same JVM, but that JBoss applies its
own policy.

>> The solution is to make sure that Java uses the unlimited strength
>> Cryptographic Jurisdiction Policy, see
>>
> https://www.firebirdsql.org/file/documentation/drivers_documentation/java/faq.html#encryption-key-did-not-meet-algorithm-requirements-of-symmetricarc4-337248282
>>
>> and
>>
> https://stackoverflow.com/questions/3862800/invalidkeyexception-illegal-key-size/3864276#3864276
> Am i correct, that every jre 8 version 161+ should work out of the
> box, or did i misunderstood the stackoverflow topic?

With Oracle Java 8 update 161 and higher, it is the default setting (it
might be different for other Java vendors than Oracle). However this
setting can be changed.

>> Alternatively, as a workaround, you can reduce the Firebird wire
>> encryption requirements by setting WireCrypt in firebird.conf from
>> its
>> default of Required to Enabled. Then Firebird will allow Jaybird to
>> connect without encryption.
> We have tried setting WireCrypt = Enabled within firebird.com, but
> within JBoss the connection did not work.

Changing this setting should work. Make sure there is no # before the
line, and you will need to restart Firebird after changing the setting
for it to work. The cause of the error itself is that Jaybird announced
it could use encryption, and then Firebird - if it requires encryption -
will reject the connection if Jaybird doesn't start encryption before
the connection phase is complete.

> I will check the java versions and the crypto policies tomorrow and
> will give you an update.

Otherwise it would be helpful to have more logs to see if there is
anything else that could cause this.

> Thanks a lot.

You're welcome!

Mark