Re: [Ejbca-develop] EJBCA 6.1.1 connectivity from client java application

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Dears,
(there was wrong typing in EJBCA version in my previous post , so repeating
the question in a correct way)
Could you please to confirm/refute whether EJBCA 3.11.0 versus EJBCA 6.1.1
has any difference in their external interfaces for interaction with
external java applications ?
Is some custom java applicaton (which was designed for interaction with
EJBCA 3.11.0 (r10752) external interface) compatible with EJBCA 6.1.1
external interface ?

thanks, Timur

2014-06-08 17:26 GMT+06:00 Branko Majic <br...@ma...>:

> On Sat, 7 Jun 2014 23:04:37 +0600
> Тимур <tim...@gm...> wrote:
>
> > Hello, Branko !
> > Thank you for your good advice about SSL debugging on JBoss.  IP-address
> > was replaced by FQDN but still JBoss rejects connection.
> > Then SSL debug had been enabled on JBoss 7.1.1:
> >
> > [oracle@duo ~]$ curl -v "https://rootca.teka.kz:8442/ejbca" -E
> > /home/oracle/CSR_EJBCA_duo2/certs_x509/duo.cer
> > --key /home/oracle/CSR_EJBCA_duo2/duo/duo.teka.kz.key --pass welcome123
> > --cacert /home/oracle/BTAIpotekaCA.cacert.pem
> > ....
> > 21:10:53,179 INFO  [stdout] (http--0.0.0.0-8442-Acceptor-0) Is initial
> > handshake: true
> > 21:10:53,180 INFO  [stdout] (http--0.0.0.0-8442-Acceptor-0) Is secure
> > renegotiation: false
> > 21:10:53,183 INFO  [stdout] (http--0.0.0.0-8442-1) http--0.0.0.0-8442-1,
> > setSoTimeout(60000) called
> > 21:10:53,187 INFO  [stdout] (http--0.0.0.0-8442-1) http--0.0.0.0-8442-1,
> > READ:  SSL v2, contentType = Handshake, translated length = 95
> > 21:10:53,190 INFO  [stdout] (http--0.0.0.0-8442-1) *** ClientHello, TLSv1
> > .....
> > 21:10:53,286 INFO  [stdout] (http--0.0.0.0-8442-1) *** ServerHello, TLSv1
> > .....
> > 21:10:53,550 INFO  [stdout] (http--0.0.0.0-8442-1) *** ServerHelloDone
> > 21:10:53,552 INFO  [stdout] (http--0.0.0.0-8442-1) http--0.0.0.0-8442-1,
> > WRITE: TLSv1 Handshake, length = 2722
> > 21:10:53,561 INFO  [stdout] (http--0.0.0.0-8442-1) http--0.0.0.0-8442-1,
> > READ: TLSv1 Alert, length = 2
> > 21:10:53,563 INFO  [stdout] (http--0.0.0.0-8442-1) http--0.0.0.0-8442-1,
> > RECV TLSv1 ALERT:  fatal, unknown_ca
> > 21:10:53,564 INFO  [stdout] (http--0.0.0.0-8442-1) http--0.0.0.0-8442-1,
> > called closeSocket()
> > 21:10:53,566 INFO  [stdout] (http--0.0.0.0-8442-1) http--0.0.0.0-8442-1,
> > handling exception: javax.net.ssl.SSLHandshakeException: Received fatal
> > alert: unknown_ca
> > 21:10:53,567 INFO  [stdout] (http--0.0.0.0-8442-1) http--0.0.0.0-8442-1,
> > IOException in getSession():  javax.net.ssl.SSLHandshakeException:
> Received
> > fatal alert:
> > unknown_ca   <-------!!!!!!!
> > 21:10:53,577 INFO  [stdout] (http--0.0.0.0-8442-1) http--0.0.0.0-8442-1,
> > called close()
> >
> > JBoss SSL-certificate is for CN=rootca.teka.kz which belongs to the CA
> > named "ROOTCA.TEKA.KZ <http://rootca.teka.kz/>".
> > BUT I run "curl" utlity for CA named "BTA Ipoteka CA" - all certificates
> > used in "curl" options are emitted by CA "BTA Ipoteka CA":
> >
> > [oracle@duo ~]$ curl -v "https://rootca.teka.kz:8442/ejbca" -E
> > /home/oracle/CSR_EJBCA_duo2/certs_x509/duo.cer \
> > --key /home/oracle/CSR_EJBCA_duo2/duo/duo.teka.kz.key --pass welcome123 \
> > --cacert /home/oracle/BTAIpotekaCA.cacert.pem
> >
> > I cannot use CA "ROOTCA.TEKA.KZ <http://rootca.teka.kz/>" as it has too
> > strong key which is not supported by my eToken Client; I had to create
> one
> > more CA "BTA Ipoteka CA" with shorter key length.
> > What steps to do if certificates for customer devices are emitted by CA
> > "BTA Ipoteka CA" but initial CA is "ROOTCA.TEKA.KZ <
> http://rootca.teka.kz/>"
> > and JBoss certificate is for initial CA.
> > Probably some reconfiguration are to be done on JBoss to let one receive
> > requests for new CA also ?
> >
> > thank you for your great job, Timur.
> >
> >
> >
> > 2014-06-07 17:07 GMT+06:00 Branko Majic <br...@ma...>:
> >
> > > On Fri, 6 Jun 2014 23:06:26 +0600
> > > Тимур <tim...@gm...> wrote:
> > >
> > > > Hello, dears
> > > >
> > > > I have successfuly installed EJBCA 6.1.1, JBoss 7.1.1.Final, openjdk
> 6,
> > > > Oracle 9.2.0.5, ojdbc6.jar, on Ubuntu Linux ("13.04, Raring
> Ringtail").
> > > No
> > > > any deployment and
> > > > installation mistakes for this software combination. I have
> successfully
> > > > created all profiles , add entuty and I have issued my first
> > > > SSL-certificate and write one to USB HSM with eToken Client. So, I
> have
> > > > full-functional EJBCA 6.1.1 at present.
> > > > I have a custom java-application which uses eToken authentication and
> > > this
> > > > java-application worked fine with previous version of EJBCA and I
> need to
> > > > organize connectivity between this java-application and EJBCA. There
> is a
> > > > parameter for EJBCA URL in java-application config file and I
> pointed out
> > > > this parameter to "https://10.62.2.88:8443/ejbca".
> > > > Java-application uses jdk cacerts and I imported issued certificate
> with
> > > CA
> > > > certificate of EJBCA to cacerts but no connection yet.
> > > > Checking connectivity to EJBCA by curl utility also gives negative
> > > result:
> > > >
> > > > CA-certificate in PEM-format:
> > > >
> > > > [oracle@duo ~]$ curl -v "https://10.62.2.88:8443/ejbca" -E
> > > > /home/oracle/CSR_EJBCA_duo2/certs_x509/duo.cer --key
> > > > /home/oracle/CSR_EJBCA_duo2/duo/duo.teka.kz.key --pass
> > > >
> > > > welcome123 --cacert /home/oracle/BTAIpotekaCA.cacert.pem
> > > > * About to connect() to 10.62.2.88 port 8443
> > > > *   Trying 10.62.2.88... * connected
> > > > * Connected to 10.62.2.88 (10.62.2.88) port 8443
> > > > * successfully set certificate verify locations:
> > > > *   CAfile: /home/oracle/BTAIpotekaCA.cacert.pem
> > > >   CApath: none
> > > > * SSL certificate problem, verify that the CA cert is OK. Details:
> > > > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
> > > verify
> > > > failed
> > > >
> > > > CA-certificate in BASE-64 format:
> > > >
> > > > [oracle@duo ~]$  curl -v "https://10.62.2.88:8443/ejbca" -E
> > > > /home/oracle/CSR_EJBCA_duo2/certs_x509/duo.cer --key
> > > > /home/oracle/CSR_EJBCA_duo2/duo/duo.teka.kz.key --pass
> > > >
> > > > welcome123 --cacert /home/oracle/BTAIpotekaCA.cacert-base64.cer
> --sslv3
> > > > --trace-ascii /tmp/curl.log
> > > > curl: (60) SSL certificate problem, verify that the CA cert is OK.
> > > Details:
> > > > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
> > > verify
> > > > failed
> > > > More details here: http://curl.haxx.se/docs/sslcerts.html
> > > >
> > > > EJBCA console log contains no records to understand why no
> connectivity
> > > to
> > > > EJBCA.
> > > > Could you please to help to find out which URL must be used to
> connect to
> > > > EJBCA for authentication ?  If "https://10.62.2.88:8443/ejbca" is
> > > correct
> > > > what's the reason
> > > > of trouble with EJBCA connection ?
> > > >
> > > > thank you, Timur.
> > >
> > > Hello Timur,
> > >
> > > The problem you are facing happens during the TLS handshake between the
> > > server and client, where (at least) client is unable to verify the
> > > certificate presented by JBoss.
> > >
> > > Since the TLS is handled by JBoss, you won't get any useful logging
> > > messages from EJBCA. In fact, not even JBoss as such will produce any
> > > useful debugging info. You could try enabling debugging of TLS
> > > handshake via JAVA_OPTS, though.
> > >
> > > I've noticed you are using the IP address for connecting to JBoss/EJBCA
> > > - are you sure that you have this IP address specified in your server
> > > certificate (on JBoss)? If not, that is your problem. The IP, FQDN, or
> > > hostname used for connecting has to be part of subjectAltName DNS name
> > > (or, if subjectAltName DNS name is not present, CN has to be used).
> > >
> > > As a side-note, you should avoid using IP address in certificates or
> > > for TLS connections in general, and instead rely on FQDN or hostname,
> > > with FQDN being the recommended thing to use.
> > >
> > > I hope this explanation will help you a bit :)
> > >
> > > Best regards
> > >
>
> Hello Timur,
>
> If you are getting a validation error on port 8442, that is probably
> the client-side validation failing. Keep in mind that if you deploy
> EJBCA on JBoss using default ports, port 8442 does _not_ require client
> certificate authentication.
>
> You could test if JBoss will return anything at all to you on port 8442
> with wget --no-check-certificate (just to see if content gets served),
> and then try to figure out why your client fails to validate the server
> certificate.
>
> If the JBoss certificate was issued by ROOTCA.TEKA.KZ, you will most
> definitively need to have this CA certificate in the truststore of your
> client.
>
> As for trusted client certificates on (for EJBCA commonly) port 8443,
> you will need to update the JBoss truststore to contain the new CA
> certificate (used for issuing client certificates).
>
> Best regards
>
> --
> Branko Majic
> Jabber: br...@ma...
> Please use only Free formats when sending attachments to me.
>
> Бранко Мајић
> Џабер: br...@ma...
> Молим вас да додатке шаљете искључиво у слободним форматима.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
>