Menu
▾
▴
Re: [Ejbca-develop] EJBCA 6.1.1 connectivity from client java application
|
From: Тимур <tim...@gm...> - 2014-06-09 11:56:46
|
Dear Branko, your advice works fine ! I have added JBoss certifcate (for initial ROOTCA.TEKA.KZ) to curl --cacert: [oracle@duo ~]$ curl -v "https://rootca.teka.kz: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/ROOTCA_cert/rootcatekakz.cacert.pem * About to connect() to rootca.teka.kz port 8443 * Trying 10.62.2.88... * connected * Connected to rootca.teka.kz (10.62.2.88) port 8443 * successfully set certificate verify locations: * CAfile: /home/oracle/ROOTCA_cert/rootcatekakz.cacert.pem CApath: none * SSL connection using DHE-RSA-AES256-SHA * Server certificate: * subject: /CN=rootca.teka.kz/O=BTAI/L=Almaty/C=KZ * start date: 2014-05-31 08:02:48 GMT * expire date: 2024-05-30 04:42:00 GMT * subjectAltName: rootca.teka.kz matched * issuer: /CN=rootca.teka.kz/O=BTAI/C=KZ * SSL certificate verify ok. > GET /ejbca HTTP/1.1 User-Agent: curl/7.12.1 (i386-redhat-linux-gnu) libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.1.2 libidn/0.5.6 Host: rootca.teka.kz:8443 Pragma: no-cache Accept: */* < HTTP/1.1 302 Moved Temporarily < Server: Apache-Coyote/1.1 < Location: https://rootca.teka.kz:8443/ejbca/ < Transfer-Encoding: chunked < Date: Mon, 09 Jun 2014 11:39:00 GMT * Connection #0 to host rootca.teka.kz left intact * Closing connection #0 [oracle@duo ~]$ echo $? 0 Then the same certificate (which was in curl for initial CA) was added to client's keystore; the certificate of second CA "BTA Ipoteka CA" (which produced certificate for client) also was added to client's keystore. But at client connection I see error in EJBCA console log: 17:20:08,444 INFO [stdout] (http--0.0.0.0-8443-5) 00D0: 36 B5 4A 30 56 38 EB DE 2D 0F 46 FF A8 4B D6 0D 6.J0V8..-.F..K.. 17:20:08,445 INFO [stdout] (http--0.0.0.0-8443-5) 00E0: 33 F4 8E A3 77 87 E0 C4 2F 20 EA 30 22 8A 8F B6 3...w.../ .0"... 17:20:08,446 INFO [stdout] (http--0.0.0.0-8443-5) 00F0: 31 F3 95 5F DD B1 FB 70 6F 05 FE 0B 54 BC 1F 5B 1.._...po...T..[ 17:20:08,447 INFO [stdout] (http--0.0.0.0-8443-5) 17:20:08,447 INFO [stdout] (http--0.0.0.0-8443-5) ] 17:20:08,448 INFO [stdout] (http--0.0.0.0-8443-5) *** 17:20:08,449 INFO [stdout] (http--0.0.0.0-8443-5) *** CertificateRequest 17:20:08,449 INFO [stdout] (http--0.0.0.0-8443-5) Cert Types: RSA, DSS, ECDSA 17:20:08,450 INFO [stdout] (http--0.0.0.0-8443-5) Cert Authorities: 17:20:08,451 INFO [stdout] (http--0.0.0.0-8443-5) <C=KZ, O=BTAI, CN=rootca.teka.kz> 17:20:08,451 INFO [stdout] (http--0.0.0.0-8443-5) <C=KZ, O=BTAI, CN=BTA Ipoteka CA> 17:20:08,452 INFO [stdout] (http--0.0.0.0-8443-5) *** ServerHelloDone 17:20:08,453 INFO [stdout] (http--0.0.0.0-8443-5) http--0.0.0.0-8443-5, WRITE: TLSv1 Handshake, length = 2290 17:20:08,458 INFO [stdout] (http--0.0.0.0-8443-5) http--0.0.0.0-8443-5, READ: TLSv1 Handshake, length = 269 17:20:08,459 INFO [stdout] (http--0.0.0.0-8443-5) *** Certificate chain 17:20:08,460 INFO [stdout] (http--0.0.0.0-8443-5) *** 17:20:08,461 INFO [stdout] (http--0.0.0.0-8443-5) http--0.0.0.0-8443-5, SEND TLSv1 ALERT: fatal, description = bad_certificate 17:20:08,473 INFO [stdout] (http--0.0.0.0-8443-5) http--0.0.0.0-8443-5, WRITE: TLSv1 Alert, length = 2 17:20:08,474 INFO [stdout] (http--0.0.0.0-8443-5) http--0.0.0.0-8443-5, called closeSocket() 17:20:08,475 INFO [stdout] (http--0.0.0.0-8443-5) http--0.0.0.0-8443-5, handling exception: javax.net.ssl.SSLHandshakeException: null cert chain 17:20:08,476 INFO [stdout] (http--0.0.0.0-8443-5) http--0.0.0.0-8443-5, IOException in getSession(): javax.net.ssl.SSLHandshakeException: null cert chain 17:20:08,478 INFO [stdout] (http--0.0.0.0-8443-5) http--0.0.0.0-8443-5, called close() 17:20:08,479 INFO [stdout] (http--0.0.0.0-8443-5) http--0.0.0.0-8443-5, called closeInternal(true) May be URL of EJBCA which is used by client java-application must be corrected ? I use only default ports and URL in client java-application is: https://rootca.teka.kz:8443/ejbca - s one correct to be used by client java-application ? Or some certficates are missed ? May be BASE-64 certificate format must be used instead of PEM-format on client java keystore ? Thank you a lot for great help, 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 > > |
