Jump to content
We have recently updated our Privacy Statement, available here ×

  • Common Errors in TIBCO ActiveMatrix BusinessWorks? related to SSL communication

    Manoj Chaurasia

    By Manoj Chaurasia

     Share

    #Please note, this article may contain out of date URLs due to the Spotfire Community migration. 

    Table of Contents

    This article outlines common errors encountered during TIBCO ActiveMatrix BusinessWorks? configuration for SSL communication. The objective of this article is to enable ActiveMatrix BusinessWorks? users to troubleshoot the cause of these errors before contacting Support.

    Section-I: Enabling Tracing

    For troubleshooting any problem related to SSL configuration in ActiveMatrix BusinessWorks?, it helps to enable the following tracing properties:

     Trace.Task.*=true Trace.Startup=true Trace.JC.*=true Trace.Engine=true Trace.Debug.*=true bw.plugin.http.server.debug: true

    If you are debugging from Designer, you can set the tracing properties above in a properties.cfg file under C:\tibco\designer\5.3 then specifies the location of this file as a ?Test Engine User Argument? in the ?Advanced Test Settings? window as shown below.

    Alternatively, you can specify the tracing properties in the custom properties file anywhere on your file system (e.g. in C:\test\props.cfg) and then reference the file in your C:\tibco\designer\5.3\bin\designer.tra file using the property

     java.property.testEngine.User.Args ?p c:/test/props.cfg

    [Note: After updating your designer.tra file, you must restart Designer in order for the updates to take effect.]

    If you need to change the default security provider (Entrust) to Sun?s J2SE, you must set the property

     java.property.TIBCO_SECURITY_VENDOR=j2se

    In addition, you can enable debug-level tracing for the J2SE library by setting the property

     java.property.javax.net.debug=ssl

    [Note: You must restart Designer (or the ActiveMatrix BusinessWorks? Engine) after setting the properties above in order for the updates to take effect.]

    Section-II: Common Errors

    Error message: ?iaik.security.ssl.SSLException: Server certificate rejected by ChainVerifier?

    Analysis:

    This ambiguous error message is common. However, once tracing is enabled, the debug information should reveal the underlying problem. For example,

     ssl_debug(1): Starting handshake (iSaSiLk 3.03)... ssl_debug(1): Sending v3 client_hello message, requesting version 3.1... ssl_debug(1): Received v3 server_hello handshake message. ssl_debug(1): Server selected SSL version 3.1. ssl_debug(1): Server created new session 47:E8:48:C2:5A:F9:14:B1... ssl_debug(1): CipherSuite selected by server: SSL_RSA_WITH_RC4_128_MD5 ssl_debug(1): CompressionMethod selected by server: NULL ssl_debug(1): Received certificate handshake message with server certificate. ssl_debug(1): Server sent a 1024 bit RSA certificate, chain has 2 elements.  validating certificate chain  looking in datastore for certificate with DN ou=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign,ou=VeriSign International Server CA - Class 3,ou=VeriSign, Inc.,o=VeriSign Trust Network  No match found  CA certificate with issuer ou=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign,    ou=VeriSign International Server CA - Class 3,    ou=VeriSign, Inc.,    o=VeriSign Trust Network and serial number 03D4 12D3 0672 7D3A 368A 9621 FCD2 357D is not a trusted certificate  server verification failed:  com.tibco.security.AXSecurityException:     CA certificate with issuer ou=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign,     ou=VeriSign International Server CA - Class 3,ou=VeriSign, Inc.,     o=VeriSign Trust Network and serial number 03D4 12D3 0672 7D3A 368A 9621 FCD2 357D is not a trusted certificate at com.tibco.security.CertChainVerifier.validateAndCompleteChain(CertChainVerifier.java:171) at com.tibco.security.ssl.DefaultCertificateVerifier.authenticateServer(DefaultCertificateVerifier.java:129) at com.tibco.security.ssl.ExtendedCertificateVerifier.authenticateServer(ExtendedCertificateVerifier.java:119) at com.tibco.security.ssl.entrust6.c.verifyServer(EntrustVerifier.java) at com.tibco.security.ssl.entrust6.c.verifyChain(EntrustVerifier.java) at iaik.security.ssl.x.a(Unknown Source) at iaik.security.ssl.x.b(Unknown Source) at iaik.security.ssl.x.a(Unknown Source) at iaik.security.ssl.r.d(Unknown Source) at iaik.security.ssl.SSLTransport.startHandshake(Unknown Source) at iaik.security.ssl.SSLTransport.a(Unknown Source) at iaik.security.ssl.SSLTransport.renegotiate(Unknown Source) at iaik.security.ssl.SSLSocket.renegotiate(Unknown Source) at com.tibco.security.ssl.entrust6.b.doHandshake(SSLClientImpl.java) at com.tibco.plugin.share.security.TIBCryptClientSocketFactory.createSocket(TIBCryptClientSocketFactory.java:76) at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:652) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:628) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:497) at com.tibco.plugin.share.http.client.JakartaHttpTransportDriver$RequestExecutor.run(JakartaHttpTransportDriver.java:227) at com.tibco.pe.util.ThreadPool$ThreadPoolThread.run(ThreadPool.java:99) ssl_debug(1): Sending alert: Alert Fatal: bad certificate ssl_debug(1): Shutting down SSL layer... ssl_debug(1): SSLException while handshaking: Server certificate rejected by ChainVerifier

    The above trace indicates that the server returned two certificates as part of its authentication and that the intermediate certificate corresponding to the DN information below was not found in the datastore (namely, the trusted certificate(s) folder) configured for this activity.

    >>looking in datastore for certificate with DN ou=www.verisign.com/CPS Incorp.by ref. >>LIABILITY LTD.©97 VeriSign,ou=VeriSign International Server CA - Class >>3,ou=VeriSign, Inc.,o=VeriSign Trust Network

    >>No match found

    Resolution:

    Once the missing certificate is imported, the error should no longer be displayed and the configuration problem should be resolved.

    [Note: ActiveMatrix BusinessWorks requires all intermediate and root certificates to be uploaded into the trusted certificate(s) folder, but the leaf certificate itself is not required to be uploaded.]

    To inspect the certificates, you can use an open-source tool like OpenSSL, cURL or Portecle. The following instructions apply to the use of Portecle:

    1. Download the Portecle package

    2. Download Bouncy Castle (BC) Crypto libraries

    3. Download Unlimited Strength JCE Policy files

    4. Navigate to your C:\\jre\lib\security\java.security file, and then use a plain text editor like Notepad to add the Bouncy Castle provider as follows:

      security.provider.N=org.bouncycastle.jce.provider.BouncyCastleProvider

      where N represents an integer which value depends on the security provider you choose for your setting. For example,

      security.provider.5=org.bouncycastle.jce.provider.BouncyCastleProvider

    5. Start Portecle from the command prompt using

       java -jar portecle.jar

    6. From the "Examine" menu, you may choose ?Examine SSL/TLS Connection? (or select other option).

    7. Enter the URL of the HTTPS server you are trying to connect to from ActiveMatrix BusinessWorks?.

      [Note: You may use the server name:port or its IP address, but the server must be visible to ActiveMatrix BusinessWorks? as well as to the machine on which Portecle is running. If the server is behind a firewall, you must request the server administrator to either allow access or provide you with the .p7b file. Additionally, the default port for HTTPS communication is 443, but it can be set differently.]

    8. Click OK to see the chain of certificates that the server is presenting.

    9. In the example above, www.bankofamerica.com is presenting two certificates in the chain. Click on the ?PEM Encoding? button to view the certificate displayed above in PEM-encoded format as shown below. You may now copy the contents of the PEM encoding for the selected certificate and save it to a local file, such as certboa1.pem. The PEM-encoded content should be between the following "begin" and "end" tags:

      -----BEGIN CERTIFICATE-----

      -----END CERTIFICATE-----

    10. Click the certificate selection arrow (shown below) to choose the next certificate in the chain presented by the server, and then proceed with the same instruction given in step 9.

    11. You may now import the copied certificates from your local file system to ActiveMatrix BusinessWorks? using the Tools menu by way of Tools > Trusted Certificates > Import into PEM format.

    The above steps can be used only if:

    1. the server is visible (i.e. publicly accessible);   and

    2. it is configured to present the complete chain. In many cases the server may present only the leaf certificate, i.e. the server certificate, in which case you must obtain the complete certificate chain from the server administrator.

    Error Message: No PrivateKeyInfo: iaik.asn1.CodingException: ASN.1 creation error:Length: Too large ASN.1 object

    Analysis:

    This error message is thrown when one attempts to start an event source which uses SSL identity of the type ?certificate/private key? instead of "PKCS#12" like .p12 or JKS keystore.

    The message indicates that the event source could not initialize the SSL server socket, because it could not find ?PrivateKeyInfo?. Examining the private key in a text editor reveals the following begin and end tags:

     -----BEGIN RSA PRIVATE KEY-----  -----END RSA PRIVATE KEY-----

    Based on which one can determine if the private key complies with PKCS#8, which is the only private key format supported in ActiveMatrix BusinessWorks.

    [Note: ActiveMatrix BusinessWorks supports only PKCS#8 private key format.]

    Resolution:

    Since the displayed key format is not PKCS#8-compliant, it must be converted with a tool like OpenSSL using the following command:

     pkcs8 -in  -inform PEM -topk8 -out .

    The output file from the above command should display the certificate with the following begin and end tags:

     -----BEGIN ENCRYPTED PRIVATE KEY-----  -----END ENCRYPTED PRIVATE KEY-----

    When you specify the output file for the PKCS#8 format in your ActiveMatrix BusinessWorks? SSL identity, the server socket should be initialized.

    [Note: If you have other private key formats like Microsoft's .pvk, you can convert it to PKCS#8 using the tool available at http://www.drh-consultancy.demon.co.uk/pvk.html.

    Error: com.tibco.security.AXSecurityException: RSA signature failed to initialize for verifying: Unsupported keysize or algorithm parameters

    Analysis:

    The debug trace of this error message should reveal the following details:

     ssl_debug(5): Starting handshake (iSaSiLk 3.03)... ssl_debug(5): Sending v3 client_hello message, requesting version 3.1... ssl_debug(5): Starting handshake (iSaSiLk 3.03)... ssl_debug(5): Received v3 client_hello handshake message. ssl_debug(5): Client requested SSL version 3.1, selecting version 3.1. ssl_debug(5): Creating new session 78:78:DC:06:C4:6B:1C:35... ssl_debug(5): CompressionMethods supported by the client: ssl_debug(5): NULL ssl_debug(5): Sending server_hello handshake message. ssl_debug(5): Selecting CipherSuite: SSL_RSA_WITH_RC4_128_SHA ssl_debug(5): Selecting CompressionMethod: NULL ssl_debug(5): Sending certificate handshake message with server certificate... ssl_debug(5): Sending server_hello_done handshake message... ssl_debug(4): Received v3 server_hello handshake message ssl_debug(5): Server selected SSL version 3.1. ssl_debug(5): Server created new session 78:78:DC:06:C4:6B:1C:35... ssl_debug(5): CipherSuite selected by server: SSL_RSA_WITH_RC4_128_SHA ssl_debug(5): CompressionMethod selected by server: NULL ssl_debug(5): Received certificate handshake message with server certificate. ssl_debug(5): Server sent a 512 bit RSA certificate, chain has 2 elements.  validating certificate chain server verification failed: com.tibco.security.AXSecurityException:     RSA signature failed to initialize for verifying: Unsupported keysize or algorithm parameters  at com.tibco.security.CertChainVerifier.validateAndCompleteChain(CertChainVerifier.java:106) at com.tibco.security.ssl.DefaultCertificateVerifier.authenticateServer(DefaultCertificateVerifier.java:129) at com.tibco.security.ssl.ExtendedCertificateVerifier.authenticateServer(ExtendedCertificateVerifier.java:119) at com.tibco.security.ssl.entrust6.c.verifyServer(EntrustVerifier.java) at com.tibco.security.ssl.entrust6.c.verifyChain(EntrustVerifier.java) at iaik.security.ssl.x.a(Unknown Source) at iaik.security.ssl.x.b(Unknown Source) at iaik.security.ssl.x.a(Unknown Source) at iaik.security.ssl.r.d(Unknown Source)

    The trace indicates that the server authentication failed, because ActiveMatrix BusinessWorks could not verify the signature of one of the certificates (in this case the chain has two elements) using the RSA public key. Moreover, the error ?unsupported keysize or algorithm parameters? indicates that one of the certificates presented by the server has a RSA key size of 2048 bits or higher.

    [Note: Entrust, the default security provider library for ActiveMatrix BusinessWorks, does not support RSA key sizes higher than 2048 bit. Even if you change the security provider to Sun?s J2SE, it will fail for 4096 bit RSA key size.]

    Resolution:

    Identify the certificate that has RSA key size greater than 2048 and replace it with a new certificate that has a key size of 2048 bit or lower. If you choose lower size key, use 1024 bit key since 512 bit is considered weak.

    Error: iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: unexpected Message

    Analysis:

    The SSL debug trace should display the following:

     ssl_debug(1): Starting handshake (iSaSiLk 3.03)... ssl_debug(1): Sending v3 client_hello message, requesting version 3.1... ssl_debug(1): Received alert message: Alert Fatal: unexpected message. ssl_debug(1): SSLException while handshaking: Peer sent alert: Alert Fatal: unexpected message ssl_debug(1): Shutting down SSL layer... exception: Peer sent alert: Alert Fatal: unexpected message iaik.security.ssl.SSLException: Peer sent alert: Alert Fatal: unexpected message at iaik.security.ssl.r.f(Unknown Source) at iaik.security.ssl.x.b(Unknown Source) at iaik.security.ssl.x.a(Unknown Source) at iaik.security.ssl.r.d(Unknown Source) at iaik.security.ssl.SSLTransport.startHandshake(Unknown Source) at iaik.security.ssl.SSLTransport.getOutputStream(Unknown Source)

    The above trace reveals that once the SSL client (ActiveMatrix BusinessWorks?) requested SSL protocol version 3.1 from the SSL server, the SSL server rejected the request and closed the connection. This behavior by the SSL server is caused by its lack of support for SSL verison 3.1. In this case, the SSL server understands only older versions of the SSL protocol (i.e. SSL 3.0 or SSL 2.0).

    Resolution:

    ActiveMatrix BusinessWorks? does not support version 2.0 of the SSL protocol with the default security provider (contact support@tibco.com for details). For a workaround, you can change the security provider library to J2SE by setting the following property in your deployed .tra file.

     java.property.TIBCO_SECURITY_VENDOR=j2se

    If you are running your project in the Tester Engine in Designer, you have to set the property below in your C:\tibco\designer\5.3\bin\designer.tra file, and then place the security vendor property and set it to J2SE in your C:\tibco\designer\5.3\properties.cfg file.

     java.property.testEngine.User.Args -p c:/tibco/designer/5.3/properties.cfg

    [Note: You may change the location of your properties.cfg file, but in doing so you must also change it in the Tester Engine as a ?Test Engine User Argument? in the ?Advanced Test Settings? window. Additionally, you must restart Designer for the changes to take effect.]

    Error: SSLException while handshaking: Peer sent alert: Alert Fatal: decrypt error

    Analysis:

    Looking at the SSL debug trace

     ssl_debug(1): Starting handshake (iSaSiLk 3.03)... ssl_debug(1): Received v2 client hello message. ssl_debug(1): Client requested SSL version 3.1, selecting version 3.1. ssl_debug(1): Creating new session 26:A3:07:B5:8B:38:62:E6... ssl_debug(1): CompressionMethods supported by the client: ssl_debug(1): NULL ssl_debug(1): Sending server_hello handshake message. ssl_debug(1): Selecting CipherSuite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA ssl_debug(1): Selecting CompressionMethod: NULL ssl_debug(1): Temporary domestic DH parameters not set, using defaults. ssl_debug(1): Sending certificate handshake message with server certificate... ssl_debug(1): Sending server_key_exchange handshake message... ssl_debug(1): Sending server_hello_done handshake message... ssl_debug(1): Received alert message: Alert Fatal: decrypt error ssl_debug(1): SSLException while handshaking: Peer sent alert: Alert Fatal: decrypt error ssl_debug(1): Shutting down SSL layer... ssl_debug(1): Closing transport...

    As part of the client-server handshake, the client attempts to decrypt some random data using the public key of the server which is present in the certificate. The result is a decryption error indicating that the server?s private key does not correspond to the public key in its certificate. This could be due to misconfiguration.

    Resolution:

    Verify that if you select ?certificate/private key? as the type of identity, the private key (in PKCS#8 format) must correspond to that of the public key in the certificate.

    Error: SSLException while handshaking: Certificate verify message signature error!

    Analysis:

    Viewing the error message in the SSL debug trace

     ssl_debug(1): Received certificate_request handshake message. ssl_debug(1): Accepted certificate types: RSA, DSS ssl_debug(1): Accepted certificate authorities: ssl_debug(1): (empty list) ssl_debug(1): Received server_hello_done handshake message. ssl_debug(1): Sending certificate handshake message with RSA client certificate... ssl_debug(1): Sending client_key_exchange handshake message (1024 bit)... ssl_debug(2): Received certificate handshake message with client certificate ssl_debug(2): Client sent a 1024 bit RSA certificate, chain has 1 elements ssl_debug(2): Received client_key_exchange handshake message, ssl_debug(1): Sending certificate_verify handshake message... ssl_debug(2): Received certificate_verify handshake message. ssl_debug(1): Sending change_cipher_spec message... ssl_debug(1): Sending finished message... ssl_debug(2): Sending alert: Alert Fatal: bad certificate ssl_debug(2): Shutting down SSL layer... ssl_debug(2): SSLException while handshaking: Certificate verify message signature error! ssl_debug(2): Closing transport... ssl_debug(1): Exception sending message: java.net.SocketException:                Software caused connection abort: socket write error ssl_debug(1): Shutting down SSL layer...

    This error was thrown during the client authentication phase. As part of the handshake, the client sends a "CertificateVerify" message which is comprised of a digitally-signed hash of all previous messages exchanged between the server and the client until, but not including, the "CertificateVerify" message itself. When the server tries to verify the signature of the ?CertificateVerify? message using the public key of the client, which is part of the client certificate, the failure occurs indicating the possibility of a mismatch in the public and private keys on the client side.

    Resolution:

    If using the type of ?Certificate/Private Key?, ve that your client-side identityhas the private key which corresponds to the public key in the certificate.

    Error: com.tibco.security.AXSecurityException: Extension error: Certificate [n] does not have a basic constraints extension!

    Analysis:

    The above error is thrown as part of the client-server handshake when an intermediate or root CA certificate does not have the "Basic Constraints? certificate attribute set to ?true? or is absent altogether.

    According to RFC 2459, Section 4.2.1.10:

    The basic constraints extension identifies whether the subject of the certificate is a CA and how deep a certification path may exist through that CA.

    The pathLenConstraint field is meaningful only if cA is set to TRUE. In this case, it gives the maximum number of CA certificates that may follow this certificate in a certification path. A value of zero indicates that only an end-entity certificate may follow in the path. Where it appears, the pathLenConstraint field MUST be greater than or equal to zero. Where pathLenConstraint does not appear, there is no limit to the allowed length of the certification path.

    This extension MUST appear as a critical extension in all CA certificates. This extension SHOULD NOT appear in end entity certificates.
     id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } BasicConstraints ::= SEQUENCE { CA BOOLEAN DEFAULT FALSE, pathLenConstraint INTEGER (0..MAX) OPTIONAL }

    Resolution:

    Check the certificates presented during the handshake and verify that intermediate CA?s and root CA?s have the "Basic Constraints" attribute and its value is set to ?TRUE?, which indicates that it can sign other leaf certificates in its hierarchy.

    Error: com.tibco.security.AXSecurityException: Extension error: certificate at index 0 is marked CA certificate

    Analysis:

    This error is thrown when the leaf certificate has the "Basic Constraints" extension marked ?CA: TRUE?, indicating that it can sign other certificates under it. However, the leaf certificates (server or client) should either omit this attribute altogether or give the value ?CA: FALSE? (see RFC 2459, Section 4.2.1.10 on the "Basic Constraints? attribute).

    Resolution:

    Identify the certificate that is causing the exception above. If it is a leaf certificate, then a new certificate would need to be generated omitting the basic constraints attribute.

    Error: java.io.IOException: Fatal SSL handshake error: java.lang.RuntimeException: Unable to create cipher AES/CBC/NoPadding: java.lang.SecurityException: Unsupported keysize or algorithm parameters

    Analysis:

    Although this error is similar to the one thrown when RSA key size is higher than 2048 bit, the clue is in the message ?Unable to create cipher AES/CBC/NoPadding? which indicates that key size for symmetric encryption is not supported. For bulk encryption, the United States government restricts the size of the symmetric key and has export regulations for software that is sold to other countries. By default, the Java runtime has only "Limited Strength" policy files (specifically, less than 128 bit key size for symmetric encryption).

    Resolution:

    Download ?Unlimited Strength? policy files from the Sun website and replace the existing files following these instructions:.

    1. Go to http://java.sun.com/j2se/1.4.2/download.html

    2. Download Java Cryptography Extension (JCE) and Unlimited Strength Jurisdiction Policy Files 1.4.2. This zip file contains two jar files: local_policy.jar and US_export_policy.jar

    3. Go to the {java home} installation (or if your TIBCO installation is using its bundled jre, go to C:\TIBCO HOME\jre\1.4.2\lib\security) and replace the existing policy files with the new ones from the Sun website

    Error: com.tibco.security.AXSecurityException: No certificates encoded in supported ways were found

    Analysis:

    The above error is thrown in ActiveMatrix BusinessWorks when you place an identity or some other activity in the same folder as the trusted certificates folder. When ActiveMatrix BusinessWorks? loads, it tries to read the identity file or other resource as a PEM-encoded X509 certificate and throws the above exception. Though the above exception has no impact on running the ActiveMatrix BusinessWorks? engine, it is good practice to keep only PEM-encoded certificates in the trusted certificates folder.

    Resolution:

    Remove other activities that might be in the trusted certificates folder from your ActiveMatrix BusinessWorks? project and keep only PEM-encoded certificates in this folder.

    Error: java.io.IOException: An AXSecurityException was thrown while trying to create the server socket on the port: [xxxx]

    Analysis:

    This exception indicates that a secure server socket could not be opened at the given port [xxxx]. In order to initialize the server socket, a valid private key and pass phrase is required. If you are using JKS keystore as an identity then make sure the keystore also contains the private key for the leaf certificate. For example, the command

    >>keytool ?list ?v ?keystore {keystore name}

    will output the following contents of the keystore on the console:

    Alias name: mykey

    Creation date: Feb 7, 2006

    Entry type: trustedCertEntry

    Owner: CN=x.y.z, OU=Domain Control Validated - Power Server ID,

    OU=See www.geotrust.com/resources/cps ©05, OU=businessprofile.geotrust.com/ge

    t.jsp?GT93606005, O=x.y.z, C=SE

    Issuer: OU=Equifax Secure Certificate Authority, O=Equifax, C=US

    Serial number: 5a733

    Valid from: Fri Jan 20 01:06:24 PST 2006 until: Sun Jan 21 01:06:24 PST 2007

    Certificate fingerprints:

    MD5: 65:88:CC:CC:02:64:64:A8:E6:DE:89:C4:26:BF:E6:B2

    SHA1: 3B:49:5A:1F:C8:F1:53:7B:F9:91:56:0F:7C:A4:C6:21:CC:EE:C1:AF

    The above keystore does not have ?Entry type? as ?keyEntry?. Instead, it has ?trustedCertEntry? which means that this keystore does not have the private key corresponding to the above certificate.

    Resolution:

    Create the key and import the signed certificate in the same keystore using the following commands:

    1.  keytool -genkey  -v -alias {alias} -keystore {keystore name} -storepass {keystore password}         -keysize 1024 -keypass {key password} -validity {no. days of validity}

    2.  keytool -certreq -v -alias {alias} -keystore {keystore name} -storepass {keystore password}          -keypass {key password} -file {certificate file name request}

    3.  keytool ?import  ?v ?alias {alias} -keystore {keystore name} -storepass {keystore password}

    Error: java.lang.IllegalArgumentException: Child resource has null name

    Analysis:

    This is a misleading error thrown when an otherwise valid certificate is imported into Designer using Tools > Trusted Certificates > Import into PEM format. The problem is Designer does not like the forward slash character in the common name attribute. For example, a cert

    > s:/C=CA/ST=Ontario/L=Toronto/O=support/OU=tibco/CN=bala.com/rdt/gdr/

    > emailAddress=bala@bala.com

    has the common name, CN= bala.com/rdt/gdr/.

    In this example, Designer would complain about the forward slash by throwing the above exception.

    Resolution:

    This behavior has been marked as a defect and should be addressed in future ActiveMatrix BusinessWorks release (you may contact support@tibco.com for more details).

    In the interim, you may choose one of the following workarounds:

    1. Create a folder in Designer, and then manually open the folder, copy-paste the certificate content in .pem format and rename the file with .cert extention.

    2. Use the global variable BW_GLOBAL_TRUSTED_CA_STORE and point to the location of the PEM-encoded certificates (e.g. file:///C:/certs/bwcert.pem).

    Error: ssl_debug(2): No client certificate available, sending empty certificate message...

    Analysis:

    From the SSL debug trace

     ssl_debug(2): Received v3 server_hello handshake message. ssl_debug(2): Server selected SSL version 3.1. ssl_debug(2): Server created new session F9:46:DB:14:3A:94:A8:0E... ssl_debug(2): CipherSuite selected by server: SSL_RSA_WITH_RC4_128_SHA ssl_debug(2): CompressionMethod selected by server: NULL ssl_debug(2): Received certificate handshake message with server certificate. ssl_debug(2): Server sent a 1024 bit RSA certificate, chain has 3 elements. validating certificate chain looking in datastore for certificate with DN cn=VeriSign Class 3 Secure Intranet Server CA,     ou=Terms of use at https://www.verisign.com/rpa (c)03,ou=VeriSign Trust Network,o=VeriSign, Inc.,c=US match found looking in datastore for certificate with DN ou=VeriSign Trust Network,     ou=(c) 1998 VeriSign, Inc. - For authorized use only,ou=Class 3 Public Primary Certification Authority - G2,     o=VeriSign, Inc.,c=US match found chain length: 3 chain verifies ok server verification ok ssl_debug(2): Received certificate_request handshake message. ssl_debug(2): Accepted certificate types: RSA, DSS, SSLv3 ephemeral RSA ssl_debug(2): Accepted certificate authorities: ssl_debug(2): cn=VeriSign Class 3 Secure Intranet Server CA,ou=Terms of use at https://www.verisign.com/rpa (c)03,               ou=VeriSign Trust Network,o=VeriSign, Inc.,c=US ssl_debug(2): cn=it-wrapper.com,ou=For Intranet Use Only,ou=Terms of use at www.verisign.com/rpa (c)00,               ou=18-l2e0,o=ABC,l=PA,st=CA,c=US ssl_debug(2): ou=VeriSign Trust Network,ou=(c) 1998 VeriSign, Inc. - For authorized use only,               ou=Class 3 Public Primary Certification Authority - G2,o=VeriSign, Inc.,c=US ssl_debug(2): Received server_hello_done handshake message. ssl_debug(2): No client certificate available, sending empty certificate message... ssl_debug(2): Sending client_key_exchange handshake message (1024 bit)... ssl_debug(2): Sending change_cipher_spec message... ssl_debug(2): Sending finished message... ssl_debug(2): Exception sending message: java.net.SocketException: Software caused connection abort:               socket write error ssl_debug(2): Shutting down SSL layer... ssl_debug(2): IOException while handshaking: Software caused connection abort: socket write error

    As you see no client certificate was sent back to the server even though the server was requesting the client to send its certificate. This is because the identity that was configured for the SSL client for client authentication has only the leaf certificate inside the .p12 file. Moreover, the signer of the client certificate is not part of the trusted certificates list of the server (referring to the list that is sent as part of the handshake after the debug statement ssl_debug(2): Accepted certificate authorities).

    As a result, the ActiveMatrix BusinessWorks security provider library (Entrust or J2SE) is unable to complete the certificate chain (leaf > intermediate CA > Root CA) and therefore no client certificate is sent, which is in accordance with RFC 2246, section 7.4.6:

    RFC 2246, Section 7.4.6: "If no suitable certificate is available, the client should send a certificate message containing no certificates. If client authentication is required by the server for the handshake to continue, it may respond with a fatal handshake failure alert."

    Resolution:

    The complete chain of certificates must be in your client identity file. If you are using OpenSSL, you can use the following command:

    >>openssl pkcs12 -export -in -inkey -CAfile -out

    If you have the .p12 file, but not the individual CA certificates, you can import the .p12 into Internet Explorer and then export it as shown below.

    • Click on the ?Personal? certificate you wish to ?Export?
    • Select ?Yes, export the private key? option and click Next
    • From the ?Export File Format? box, check ?Include all certificates in the certification path if possible?
    • Enter the password for the "PKCS#12" file and confirm it, then click Next
    • Provide a file name for the exported file (or browse the file) and click Next

    If the steps above do not yield the full certificate chain, contact your CA to obtain the signer certificates for your client.

    [Note: You may contact support@tibco.com for issues that are not related to the above list.]

    • Like 1
     Share
    Go to articles

    User Feedback

    Recommended Comments

    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

© 2024 Cloud Software Group, Inc. All rights reserved.
×
×
  • Create New...