two-way-ssl error in connecting: certicom.tls.record.alert

Igor Syrman

unread,

May 4, 2004, 7:37:05 AM5/4/04

to

Heya,

I'm getting trouble with browser-client connecting with two-way-ssl to WLS8.1
sp2. Client cert is from a smartcard and has one intermediate and one root ca-cert.
Connection worked fine with a cert with only one ca, but I don't really know if
thats important.

Won't go in to much detail about the settings, incase some one can point the right
direction with just the ssl-debug (but been through all the obvious ca-certs
in server and client).

So roughly what's this exception about?

--Igor

<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <SSLIOContextTable.addContext(ctx):
27844797>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <SSLSocket will be Muxing>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <SSLIOContextTable.findContext(is):
3853423>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <SSLFilter.isActivated: false>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <isMuxerActivated: false>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <SSLFilter.isActivated: false>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <17892731 readRecord()>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <17892731 SSL Version 2 with
no padding>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <17892731 SSL3/TLS MAC>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <17892731 received SSL_20_RECORD>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientHelloV2>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <write HANDSHAKE offset =
0 length = 58>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <write HANDSHAKE offset =
0 length = 3366>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Class
4 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=SHP
ROOT CA, O=SHP, C=FI>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=wss.topsel.fi,
O=Fujitsu Services Oy, C=FI>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=GTE
CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation,
C=US>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=SatShp
CA, O=Satakunnan sairaanhoitopiiri, C=FI>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Class
1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: EMAILADDRESS=persona...@thawte.com,
CN=Thawte Personal Basic CA, OU=Certification Services Division, O=Thawte Consulting,
L=Cape Town, ST=Western Cape, C=ZA>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: EMAILADDRESS=personal...@thawte.com,
CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting,
L=Cape Town, ST=Western Cape, C=ZA>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=finigostyr2,
OU=fubar, O=fujitsu, L=helsinki, ST=uusimaa, C=fi>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Class
3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=GTE
CyberTrust Root, O=GTE Corporation, C=US>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: EMAILADDRESS=server...@thawte.com,
CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc,
L=Cape Town, ST=Western Cape, C=ZA>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: EMAILADDRESS=personal...@thawte.com,
CN=Thawte Personal Premium CA, OU=Certification Services Division, O=Thawte Consulting,
L=Cape Town, ST=Western Cape, C=ZA>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: EMAILADDRESS=premium...@thawte.com,
CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting
cc, L=Cape Town, ST=Western Cape, C=ZA>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=PSHP
TEST CA, O=Pirkanmaan Sairaanhoitopiiri, C=FI>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Secure
Server Certification Authority, O="RSA Data Security, Inc.", C=US>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=Baltimore
CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=Fujitsu
Test CA, O=Fujitsu Services Oy, C=FI>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=GTE
CyberTrust Root 5, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=PSHP
CA, O=Pirkanmaan sairaanhoitopiiri, C=FI>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: CN=Baltimore
CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Class
2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <write HANDSHAKE offset =
0 length = 2598>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <write HANDSHAKE offset =
0 length = 4>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <SSLFilter.isActivated: false>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <isMuxerActivated: false>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <SSLFilter.isActivated: false>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <17892731 readRecord()>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <close(): 17892731>
<May 3, 2004 4:00:03 PM EEST> <Debug> <TLS> <000000> <NEW ALERT: com.certicom.tls.record.alert.Alert@7f0b4e
Severity: 1 Type: 0
java.lang.Throwable: Stack trace
at weblogic.security.utils.SSLSetup.debug(SSLSetup.java:265)
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.closeWriteHandler(Unknown
Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.close(Unknown Source)
at javax.net.ssl.impl.SSLSocketImpl.close(Unknown Source)
at weblogic.t3.srvr.ListenThread.rejectCatastrophe(ListenThread.java:439)
at weblogic.t3.srvr.SSLListenThread$1.execute(SSLListenThread.java:533)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

What happens here is client is requested the id-cert he wants and after selecting
it, it is asked again after which page is not found.

Igor Styrman

unread,

May 4, 2004, 9:58:36 AM5/4/04

to

It seems the severity 1 alert comes even in successfull handshake, but the real
problem spot is this:

<May 3, 2004 3:51:07 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Class

2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>

<May 3, 2004 3:51:07 PM EEST> <Debug> <TLS> <000000> <NEW ALERT: com.certicom.tls.record.alert.Alert@1091c3f
Severity: 2 Type: 42

java.lang.Throwable: Stack trace
at weblogic.security.utils.SSLSetup.debug(SSLSetup.java:265)
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)

at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
at com.certicom.tls.record.handshake.ServerStateSentHelloDone.handle(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown
Source)
at com.certicom.tls.record.ReadHandler.interpretContent(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown
Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown
Source)
at com.certicom.net.ssl.CerticomContextWrapper.forceHandshakeOnAcceptedSocket(Unknown
Source)
at weblogic.t3.srvr.SSLListenThread$1.execute(SSLListenThread.java:514)

Pavel

unread,

May 4, 2004, 12:45:45 PM5/4/04

to

Yes, the other alert was a normal close notification alert, which is sent whenever
the socket is closed. This alert is a BAD_CERTIFICATE alert, which the server
in this case sends to the client because the client's certificate failed validation.
The ssl debug messages preceiding this new alert stack might have some information
on why the certificate got rejected. The most likely reason is that the server
does not trust the CA that issued client's certificate. So, make sure the CA cert
is in the server's trusted CA keystore.

Pavel.

Igor Styrman

unread,

May 4, 2004, 1:30:35 PM5/4/04

to

Thanks for the reply Pavel, I'm gonna recheck the server-side CA's allthough done
it more than once. Here's the entire log, allthough didn't see any clear-language
errors:

<!-- CONVERTING ALL PRINCIPAL'S ->

<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Class

2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>

<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <write HANDSHAKE offset =
0 length = 2598>
<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <write HANDSHAKE offset =
0 length = 4>
<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <SSLFilter.isActivated: false>
<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <isMuxerActivated: false>
<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <SSLFilter.isActivated: false>
<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <28449506 readRecord()>
<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <close(): 28449506>
<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <NEW ALERT: com.certicom.tls.record.alert.Alert@119e82c
Severity: 1 Type: 0

java.lang.Throwable: Stack trace
at weblogic.security.utils.SSLSetup.debug(SSLSetup.java:265)
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)

at com.certicom.tls.interfaceimpl.TLSConnectionImpl.closeWriteHandler(Unknown
Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.close(Unknown Source)
at javax.net.ssl.impl.SSLSocketImpl.close(Unknown Source)
at weblogic.t3.srvr.ListenThread.rejectCatastrophe(ListenThread.java:439)
at weblogic.t3.srvr.SSLListenThread$1.execute(SSLListenThread.java:533)

at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
>

<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <avalable(): 28449506 : 0
+ 0 = 0>
<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <write ALERT offset = 0 length
= 2>
<May 3, 2004 3:50:44 PM EEST> <Debug> <TLS> <000000> <SSLIOContextTable.removeContext(ctx):
25663554>
<May 3, 2004 3:50:54 PM EEST> <Debug> <TLS> <000000> <Filtering JSSE SSLSocket>
<May 3, 2004 3:50:54 PM EEST> <Debug> <TLS> <000000> <SSLIOContextTable.addContext(ctx):
25077087>
<May 3, 2004 3:50:54 PM EEST> <Debug> <TLS> <000000> <SSLSocket will be Muxing>
<May 3, 2004 3:50:54 PM EEST> <Debug> <TLS> <000000> <SSLIOContextTable.findContext(is):
26945727>
<May 3, 2004 3:50:54 PM EEST> <Debug> <TLS> <000000> <SSLFilter.isActivated: false>
<May 3, 2004 3:50:54 PM EEST> <Debug> <TLS> <000000> <isMuxerActivated: false>
<May 3, 2004 3:50:54 PM EEST> <Debug> <TLS> <000000> <SSLFilter.isActivated: false>
<May 3, 2004 3:51:05 PM EEST> <Debug> <TLS> <000000> <7344120 readRecord()>
<May 3, 2004 3:51:05 PM EEST> <Debug> <TLS> <000000> <7344120 SSL Version 2 with
no padding>
<May 3, 2004 3:51:05 PM EEST> <Debug> <TLS> <000000> <7344120 SSL3/TLS MAC>
<May 3, 2004 3:51:05 PM EEST> <Debug> <TLS> <000000> <7344120 received SSL_20_RECORD>
<May 3, 2004 3:51:05 PM EEST> <Debug> <TLS> <000000> <HANDSHAKEMESSAGE: ClientHelloV2>
<May 3, 2004 3:51:05 PM EEST> <Debug> <TLS> <000000> <write HANDSHAKE offset =
0 length = 58>
<May 3, 2004 3:51:05 PM EEST> <Debug> <TLS> <000000> <write HANDSHAKE offset =
0 length = 3366>
<May 3, 2004 3:51:05 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Class

2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>

<!-- CONVERTING ALL PRINCIPAL'S ->

<May 3, 2004 3:51:07 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Class

4 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>

<!-- CONVERTING ALL PRINCIPAL'S ->

<May 3, 2004 3:51:07 PM EEST> <Debug> <TLS> <000000> <NEW ALERT: com.certicom.tls.record.alert.Alert@1091c3f
Severity: 2 Type: 42
java.lang.Throwable: Stack trace
at weblogic.security.utils.SSLSetup.debug(SSLSetup.java:265)
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source)
at com.certicom.tls.record.handshake.ServerStateSentHelloDone.handle(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown
Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown
Source)
at com.certicom.tls.record.ReadHandler.interpretContent(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown
Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown
Source)
at com.certicom.net.ssl.CerticomContextWrapper.forceHandshakeOnAcceptedSocket(Unknown
Source)
at weblogic.t3.srvr.SSLListenThread$1.execute(SSLListenThread.java:514)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
>

Pavel

unread,

May 4, 2004, 6:13:08 PM5/4/04

to

The validation might be failing because of the constraints in one of the certificates
in the client certificate chain. Are you saying that when you do not include the
root certificate, and set the server to trust the intermediate CA cert everything
works? If that is the case then it might be a constraint in the root CA certificate.
See what constraints this certificate has. Certicom SSLPlus ssl implementation
used by Weblogic only enforces the following critical extentions: basic constraints,
key usage, and extended key usage. It is possible that the certificate is rejected
because it contains some other extention marked as critical, which SSLPlus does
not know how to enforce.

Pavel.

Igor Styrman

unread,

May 5, 2004, 8:55:47 AM5/5/04

to

We've found a wrong field in the cert marked as critical, thanks for the insight
=)

The cert situation is that we have two separate certs, one that has only one CA
and other that has a root and intermediate CA's. The one with two CA's doesn't
work.

Actually here's the bad chain, incase you can see other problems (hope not).

Found out there's some options to cut down the validation of certs from command
line: -Dweblogic.security.SSL.enforceConstraints=off , but setting this didn't
seem to make a difference in our case.

--Igor

Pavel

unread,

May 5, 2004, 10:40:32 AM5/5/04

to

enforceConstraints flag only affects whether the basic constraints are required
and marked as critical in the CA certs.
I cannot tell much about the certs you posted, but when constraints are not critical
they are ignored. So the only other problem with the ca certs could be if there
is a problem with one of the supported critical constraints.

Pavel.

Ari Räisänen

unread,

May 6, 2004, 3:40:46 AM5/6/04

to

"Pavel" <Pav...@no.spam> wrote:
>
>enforceConstraints flag only affects whether the basic constraints are
>required
>and marked as critical in the CA certs.
>I cannot tell much about the certs you posted, but when constraints are
>not critical
>they are ignored. So the only other problem with the ca certs could be
>if there
>is a problem with one of the supported critical constraints.
>
>Pavel.

Thanks Pavel, you've been a great help to me and Igor. I opened a support case
for this problem which follows here. Any suggestions are welcome!

---8<--------------------------------------------------------------------------

You should read the following thread in weblogic.developer.interest.security newsgroup
for background information. The reason was found there but the solution not yet.

http://newsgroups2.bea.com/cgi-bin/dnewsweb?utag=&group=weblogic.developer.interest.security&xrelated=12439&cmd_thread_last.x=44&cmd_thread_last.y=15

We are using WLS and 2-way-SSL for client authentication. Our user (client) certificates
have one extension field (SubjectAlternativeName) marked as critical as you can
see in the following base64 encoded cert.

Some additional info on the extension in question:
---
SubjectAlternativeName (OID 2.5.29.17) extension in user certificate is marked
as critical.

SEQUENCE [76] {
OBJECT_ID [3] "2.5.29.17" -- subjectAltName
BOOLEAN [1] ff
OCTET_STRING [66]
3040a026 060a2b06 01040182 37140203 a0180c16 6173656e 6e757369 6e766961
40736174 7368702e 66698116 6173656e 6e757369 6e766961 40736174 7368702e
6669 }

SubjectAlternativeNames =
Following names detected =
EMAIL (rfc822), UPN (principal name)
Viewing specific name types =
EMAIL = asennu...@satshp.fi
UPN = <asennu...@satshp.fi>
[CRITICAL]
---

The problem is that Weblogic cannot handle this user certificate and throws on
exception for BAD_CERTIFICATE and the 2-way-SSL handshake fails. Here's a clip
from the ssl debug log.

<May 3, 2004 3:51:07 PM EEST> <Debug> <TLS> <000000> <Converting principal: OU=Class
2 Public Primary Certification Authority, O="VeriSign, Inc.", C=US>
<May 3, 2004 3:51:07 PM EEST> <Debug> <TLS> <000000> <NEW ALERT: com.certicom.tls.record.alert.Alert@1091c3f
Severity: 2 Type: 42 java.lang.Throwable: Stack trace at weblogic.security.utils.SSLSetup.debug(SSLSetup.java:265)
at com.certicom.tls.record.alert.Alert.<init>(Unknown Source) at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown
Source) at com.certicom.tls.record.handshake.ServerStateSentHelloDone.handle(Unknown
Source) at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessage(Unknown
Source) at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown
Source) at com.certicom.tls.record.ReadHandler.interpretContent(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source) at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown
Source) at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown
Source) at com.certicom.net.ssl.CerticomContextWrapper.forceHandshakeOnAcceptedSocket(Unknown
Source) at weblogic.t3.srvr.SSLListenThread$1.execute(SSLListenThread.java:514)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

Quote from Pavel (see the newsgroup thread I mentioned):

"Certicom SSLPlus ssl implementation used by Weblogic only enforces the following
critical extentions: basic constraints, key usage, and extended key usage. It
is possible that the certificate is rejected because it contains some other extention
marked as critical, which SSLPlus does not know how to enforce."

This seems really to be the problem. Any suggestions what to do and how to get
around this problem? Is there any way to configure the ssl implementation to accept
our client certs? Would changing java.protocol.handler.pkgs (to what?) solve anything?