login about faq

I have about 2,000 clients running an application that connects to a Windows Azure server with Chilkat.Socket using TLS 1.2.

All 2,000 of the clients are connecting up just fine except for one client that is failing in validateServerCerts. This client receives two certs for some reason after it establishes the socket connection (certListSize: 2). It fails to validate the second, rogue certificate due to what appears to be a reason of 'expiredCert:'.

I call this second certificate a rogue certificate because I don't know where it is coming from -- I am only using one certificate on the Server-side. Also, the properties of the certificate in the chilkat log indicate that it is from an unknown source (it's not a server certificate of ours).

Below is the Chilkat log when it fails to connect:

EstablishTCPConnection on port 2113: ChilkatLog:
  Connect_Socket(390ms):
    DllDate: Dec 29 2015
    ChilkatVersion: 9.5.0.55
    UnlockPrefix: E3TEKC.CBX0816
    Username: ESITE007xx:SYSTEM
    Architecture: Little Endian; 32-bit
    Language: .NET 2.0
    VerboseLogging: 1
    objectId: 2
    Component successfully unlocked using purchased unlock code.
    connectInner(390ms):
      hostname: 40.118.254.111
      port: 2113
      tls: 1
      maxWaitMs: 30000
      socket2Connect(390ms):
        connect2(390ms):
          hostname: 40.118.254.111
          port: 2113
          ssl: 1
          connectImplicitSsl(390ms):
            Clearing TLS client certificates.
            connectSocket(62ms):
              domainOrIpAddress: 40.118.254.111
              port: 2113
              connectTimeoutMs: 30000
              connect_ipv6_or_ipv4(62ms):
                This is an IPV4 numeric address.
                Domain to IP address resolution not needed.
                connecting to IPV4 address...
                ipAddress: 40.118.254.111
                createSocket:
                  Setting SO_SNDBUF size
                  sendBufSize: 262144
                  Setting SO_RCVBUF size
                  recvBufSize: 4194304
                --createSocket
                connect(62ms):
                  Waiting for the connect to complete...
                  myIP: 192.168.2.70
                  myPort: 62988
                  socket connect successful.
                --connect
              --connect_ipv6_or_ipv4
            --connectSocket
            clientHandshake(328ms):
              The client cert chain is NULL.
              cacheClientCerts:
                Cached TLS client certificates.
                Client cert chain is NULL.
              --cacheClientCerts
              clientHandshake2(328ms):
                readHandshakeMessages(78ms):
                  processHandshakeRecord:
                    processHandshakeMessage:
                      processServerHello:
                        negotiatedTlsVersion: TLS 1.2
                        negotiatedCipherSuite: TLS_RSA_WITH_AES_128_CBC_SHA256
                        minAcceptableRsaKeySize: 1024
                      --processServerHello
                    --processHandshakeMessage
                  --processHandshakeRecord
                --readHandshakeMessages
                buildClientKeyExchange:
                  buildClientKeyExchangeRsa:
                    modulus_bitlen: 2048
                    bigEndian: 1
                    padding: PKCS 1.5
                  --buildClientKeyExchangeRsa
                --buildClientKeyExchange
              --clientHandshake2
            --clientHandshake
            checkServerCert:
              Verifying server certificate...
              validateServerCerts:
                **certListSize: 2**
                verifyCertSignature:
                  certSubject: localhost, TheExpectedDomain.cloudapp.net
                  issuerDN: com, rogue, rogueDN
                  issuerSerialNumber: 7C2DAAB70DBBB8B049F565B747379E44
                  CertSignatureAlgorithmOid: 1.2.840.113549.1.1.11
                  unsignSslSig:
                    Zero-extending to match modulus byte length
                  --unsignSslSig
                  HashAlgorithmOid: 2.16.840.1.101.3.4.2.1
                  SignatureVerified: 1
                --verifyCertSignature
                verifyCertSignature:
                  certSubject: com, rogue, rogueDN
                  Verifying the signature of a self-signed/root certificate.
                  CertSignatureAlgorithmOid: 1.2.840.113549.1.1.5
                  unsignSslSig:
                    Zero-extending to match modulus byte length
                  --unsignSslSig
                  HashAlgorithmOid: 1.3.14.3.2.26
                  SignatureVerified: 1
                  This is an implicitly trusted root certificate.
                --verifyCertSignature
                expiredCert: com, rogue, rogueDN
              --validateServerCerts
              SSL server certificate verification failed.
            --checkServerCert
            Server certificate verification failed. (3)
          --connectImplicitSsl
          ConnectFailReason: Server certificate validation failed
        --connect2
      --socket2Connect
      Failed.
    --connectInner
    Failed.
  --Connect_Socket
--ChilkatLog

Notice above that the certlistSize is two but it should be one. The server is only using the one certificate (TheExpectedDomain.cloudapp.net) so I don't know where the additional rogue cert is coming from. When I connect with Verbose Logging enabled on the other ~2,000 working clients, only one certificate is validated in ValidateServerCerts and the certListSize is always = 1.

Does anyone have an idea as to where this second cert could be coming from? In the server-side service when I begin listening on the TLS port I am only using one certificate when I call InitSSLServer(cert) so I don't understand why this particular client is trying to validate a second certificate from an unknown source.

On the server-side I am using a self-signed certificate that I created when calling InitSSLServer(). Does that not make any difference in terms of the server sending a whole chain of certs to the client instead of just my single, self-signed cert?

Below is my server-side code that sets up the certStore and binds and listens on the socket:

        Chilkat.CertStore certStore = new Chilkat.CertStore();
        success = certStore.LoadPfxFile("C:\\MySelfSignedCert.pfx", "mycertpassword");
        if (success != true)
        {
            LogException(certStore.LastErrorText);
            return;
        }

        Chilkat.Cert cert = null;
        cert = certStore.GetCertificate(0); //get the cert in the store at index 0
        if (cert == null)
        {
            LogException(certStore.LastErrorText);
            return;
        }
        tcpSocket.SoReuseAddr = true;
        tcpSocket.VerboseLogging = true;
        tcpSocket.Ssl = true;
        tcpSocket.SslProtocol = "TLS 1.2";
        tcpSocket.SslAllowedCiphers = "TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA";

        //  Use the certificate:

        success = tcpSocket.InitSslServer(cert);

        if (success != true)
        {
            LogException(tcpSocket.LastErrorText);
            return;
        }

        tcpSocket.BindAndListen(port, 50);

asked Apr 20 at 17:14

Moraeulf's gravatar image

Moraeulf
32

edited Apr 21 at 11:22


In the SSL/TLS handshake protocol,when the server send's it's "Server Certificate" message, it's not just sending one certificate -- it's sending the server's certificate chain to the client. (i.e. the certs in the chain of authentication to the root, which could include intermediate certs). See Section 7.4.2 of RFC 5246 if you want to know the specifics..

(Of course, if the certs in the chain of authentication are not available to the server, then it may just send only it's cert, in which case the client may have the remainder of the chain already installed on it's system. In general, the root CA cert would need to be a trusted root, and the fact that it may be included as part of the ServerCertificate TLS handshake message is redundant.)

link

answered Apr 20 at 19:49

chilkat's gravatar image

chilkat ♦♦
12.8k317363471

Thanks for the reply. I've added some more comments to my original question in addition to the server-side code that sets up the certStore and the listening socket.

I'm using a self-signed certificate on the server.

I'll take some time to read 7.4.2 of RFC 5246.

(Apr 21 at 11:19) Moraeulf

Since the client is trying to validate the server certificate identified by [issuerDN: com, rogue, rogueDN issuerSerialNumber: 7C2DAAB70DBBB8B049F565B747379E44]

Would I expect to find that certificate in my server's list of certificates?

I searched through a dump of all certificates installed on my server and found zero occurrences of 'rogue' or 'rogueDN' or the serial number 7C2DAAB70DBBB8B049F565B747379E44, so I am clueless as to where this certificate could be coming from.

All of my other 2,000 clients behave as expected - only 1 cert is received from the server and validated.

Thanks

(Apr 21 at 19:48) Moraeulf
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×81
×51
×40
×4

Asked: Apr 20 at 17:14

Seen: 431 times

Last updated: Apr 21 at 19:48

powered by OSQA