Menu
▾
▴
Re: [Ejbca-develop] EJBCA 6.1.1 connectivity from client java application
|
From: Тимур <tim...@gm...> - 2014-06-11 09:57:44
|
Hello, dears ! I have an error at connection to my EJBCA from client application: JBoss server.log: ...... 15:07:21,136 INFO [stdout] (http--0.0.0.0-8443-3) <C=KZ, O=BTAI, CN=BTA Ipoteka CA> 15:07:21,137 INFO [stdout] (http--0.0.0.0-8443-3) <C=KZ, L=Almaty, O=BTA Ipoteka, CN=duo2.teka.kz> 15:07:21,138 INFO [stdout] (http--0.0.0.0-8443-3) *** ServerHelloDone 15:07:21,138 INFO [stdout] (http--0.0.0.0-8443-3) http--0.0.0.0-8443-3, WRITE: TLSv1 Handshake, length = 2369 15:07:21,161 INFO [stdout] (http--0.0.0.0-8443-3) http--0.0.0.0-8443-3, READ: TLSv1 Alert, length = 2 15:07:21,162 INFO [stdout] (http--0.0.0.0-8443-3) http--0.0.0.0-8443-3, RECV TLSv1 ALERT: fatal, certificate_unknown 15:07:21,163 INFO [stdout] (http--0.0.0.0-8443-3) http--0.0.0.0-8443-3, called closeSocket() 15:07:21,164 INFO [stdout] (http--0.0.0.0-8443-3) http--0.0.0.0-8443-3, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown 15:07:21,178 INFO [stdout] (http--0.0.0.0-8443-3) http--0.0.0.0-8443-3, IOException in getSession(): javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown 15:07:21,180 INFO [stdout] (http--0.0.0.0-8443-3) http--0.0.0.0-8443-3, called close() 15:07:21,181 INFO [stdout] (http--0.0.0.0-8443-3) http--0.0.0.0-8443-3, called closeInternal(true) BUT curl running on remote client side shows valid connection to EJBCA : [oracle@duo Cerber_inet]$ 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: Wed, 11 Jun 2014 09:05:35 GMT * Connection #0 to host rootca.teka.kz left intact * Closing connection #0 Client application server log: ..... [SOAPException: faultCode=SOAP-ENV:IOException; msg=sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target; targetException=javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] at oracle.soap.transport.http.OracleSOAPHTTPConnection.send(OracleSOAPHTTPConnection.java:774) There are few CAs (with different key length) in my EJBCA : Management CA ROOTCA.TEKA.KZ <http://rootca.teka.kz/> <----initially created BTA Ipoteka CA <-----created later - Client host has name "duo.teka.kz" and each CA (ROOTCA and BTA Ipoteka) issued the certificate for "duo.teka.kz" - both certificates are loaded to jks.store on client-side application server. - Both CA certficates of each CA (ROOTCA and BTA Ipoteka) are loaded to to jks.store on client-side application server. I took them from CA structure page of EJBCA adminweb. - CA certficate of BTA Ipoteka was loaded to JBoss truststore. Both JBoss 7.1.1.Final and remote Oracle Application Server 10g were restarted. I cannot understand which CA certificate is missed as both JBoss truststore and remote client side jks.store contains certficates of both CA. Could you please to help ? Detailed logs are attached to my previous message. Thank you, 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 > > |
