Hi Rob,

thanks a lot for your answer - as you rightly assumed, the service provider 
expects SSL client authentication. This combination of certificate file and pem 
file finally did the trick.

Kind regards
Frank

-----Ursprüngliche Nachricht-----
Von: Rob Godfrey [mailto:[email protected]] 
Gesendet: Freitag, 12. September 2014 22:37
An: [email protected]
Betreff: Re: proton-j 0.7 problem with SSL Certificate

Hi Frank,

So... I'm a bit surprised that you received a PEM file which (from the bouncy 
castle error above) seems to contain a private key.  By definition private keys 
should be private.

The only reason a client application might need a private key is if it was 
using SSL certificates for client authentication (in a "standard" SSL 
interaction the only the server is authenticated - by providing the client a 
certificate which the client verifies has been signed by a third party it 
trusts - this is how HTTPS works by default... However you can additionally use 
SSL to identify the "client" to the server... in this case the client also 
presents a certificate (and the client application will need to posses the 
private key for its certificate)).

If you are actually requiring SSL client authentication, you would need to set 
messenger.setCertificate with the .cer file containing the certificate being 
used to identify the client, and messenger.setPrivateKey with the .pem file 
containing the private key.

-- Rob



On 12 September 2014 14:54, Dr. Frank Heuschen <[email protected]>
wrote:

> Hi Rob,
>
> thanks for your answer, but it still does not work well for me. As you 
> rightly assumed, I am working on a client application and received a 
> "trusted" certificate package containing a *.cer and a *.pem file.
>
> If I remove the two lines messenger.setCertificate and 
> messenger.setPrivateKey as suggested, and use
>
> messenger.setTrustedCertificates(certificate); with the *.cer file, I 
> receive following exception:
> org.apache.qpid.proton.engine.TransportException:
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>
> messenger.setTrustedCertificates(certificate); with the *.pem file
> yields:  org.apache.qpid.proton.engine.TransportException:
> org.apache.qpid.proton.engine.TransportException: File 
> ./src/main/config/CBKER.pem does not provide a object of the required type.
> Read an object of class
> org.bouncycastle.jcajce.provider.asymmetric.rsa.BCRSAPrivateCrtKey 
> whilst expecting an implementation of one of the following  : [class 
> java.security.cert.Certificate]
>
> If I use messenger.setCertificate (certificate); instead (just without 
> the private key statement), I have as well Exceptions for both file types:
> org.apache.qpid.proton.engine.TransportException:
> javax.net.ssl.SSLException: Received fatal alert: bad_certificate
>
> Unfortunately I am not at all an SSL expert and kind of desparate ...
>
> Kind regards
> Frank
>
> -----Ursprüngliche Nachricht-----
> Von: Rob Godfrey [mailto:[email protected]]
> Gesendet: Mittwoch, 10. September 2014 22:15
> An: [email protected]
> Betreff: Re: proton-j 0.7 problem with SSL Certificate
>
> On 5 September 2014 14:41, Dr. Frank Heuschen 
> <[email protected]>
> wrote:
>
> > Hi,
> >
> >
> >
> > I am trying out to use proton-j 0.7 to communicate with a AMQP 
> > server that always uses SSL encryption. On order to do so, we 
> > received a pem file from the organisation operating the broker.
> >
> > While the proton-c port uses this file directly and worked like a 
> > charm, in Java it is not working with SSL at all for me.
> >
> >
> >
> > I tried the following:
> >
> > /// ==== 8< ==== ///
> >
> > if (addresses.size() < 1) {
> >
> >
> > this.addresses.add("amqps://some_ip:some_port/queue://some_queue_name"
> > );
> >
> >             this.addresses.add("amqps:// some_ip:some_port 
> > /topic://some_topic_name");
> >
> >         }
> >
> > /// ==== 8< ==== ///
> >
> > messenger.start();
> >
> >
> >
> >             messenger.setCertificate("path_2_file.pem");
> >
> >             messenger.setPrivateKey("path_2_file.pem ");
> >
> >
> >
> So - I'm no expert on the Messenger API, but if you are the client 
> connecting to a server providing SSL I would expect that you should be 
> providing the certificates that you trust.  The API calls above would 
> seem to be for the case where you are writing the server and you are 
> providing the certificate and the private key for the certificate.
>
> Messenger appears to provide a method
>
>     messenger.setTrustedCertificates(String trusted);
>
> Have you tried using this, and removing the two statements above?
>
>
>
> >
> >             for (String address : addresses) {
> >
> >                 messenger.subscribe(address);
> >
> >             }
> >
> >            messenger.recv();
> >
> > /// ==== 8< ==== ///
> >
> >
> >
> > As soon as the function messenger.recv(); is called, the application 
> > is searching for classes from org. bouncycastle, which I added in 
> > the version
> > 1.47 in maven, because the desired Functions are no longer available 
> > in later versions.
> >
> >
> >
> > Afterwards (as the bouncycastle stuff is available) I always receive 
> > the following error:
> >
> >
> >
> > org.apache.qpid.proton.engine.TransportException:
> > org.apache.qpid.proton.engine.TransportException: File 
> > path_2_file.pem does not provide a object of the required type. Read 
> > an object of class 
> > org.bouncycastle.jcajce.provider.asymmetric.rsa.BCRSAPrivateCrtKey
> > whilst expecting an implementation of one of the following  : [class 
> > java.security.cert.Certificate]
> >
> >
> >
> As above - I think you are making the wrong API calls, calling
> setPrivateKey() you would need to be providing a file containing an 
> RSA Private Key... but as the client you don't need to do this - you 
> only need to provide the certificate of the server you trust, or the 
> certificate of a signing authority who has signed the certificate of your 
> server.
>
> Hope this helps,
> Rob
>
>
> > What needs to be done, to have this working with the same pem files 
> > as in C?
> > Should I convert the file to another format?
> >
> >
> >
> > Thanks an kind regards
> >
> > Frank
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] For 
> additional commands, e-mail: [email protected]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to