Menu
▾
▴
Re: [Ejbca-develop] EJBCA 6.1.1 connectivity from client java application
|
From: Branko M. <br...@ma...> - 2014-06-08 11:26:48
|
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... Молим вас да додатке шаљете искључиво у слободним форматима. |
