Your callback should have access to the Global data in your program, which can include both that file name and variables to hold on to the loaded PEM file once loaded by the first session needing it.

On 12/2/2011 12:09 PM, Rohit Bansal wrote:
Thanks Jakob,

Callback is a possibility but the limitation is that this callback does not have access to the filename (which can change for every client) to load all pem files. Also I do not want to read the file every time in call back.

I was ablt to prototype my idea by recreating the SSL object from context and use it for SSL_Connect and SSL_accept.

But unfortunately client is sending a fatal unexpected_message alert to server immediately after client hello.

here is the ssl dump:


New TCP connection #1: localhost.localdomain(10289) <-> localhost.localdomain(23037)
1 1  0.0001 (0.0001)  C>SV3.1(67)  Handshake
      ClientHello
        Version 3.1
        random[32]=
          4e d8 a4 ee fd 9e be ec 58 1b 3e 16 fd a6 b2 e9
          a5 fe 65 34 79 e4 65 03 81 d4 f2 b7 7a a8 ac 55
        cipher suites
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_IDEA_CBC_SHA
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_RC4_128_MD5
        compression methods
                  NULL
1 2  0.0005 (0.0003)  S>CV3.1(74)  Handshake
      ServerHello
        Version 3.1
        random[32]=
          4e d8 a4 ee a5 b1 69 b8 9a a1 e4 01 07 96 e4 a1
          31 dc 7d b7 e3 01 48 4e d1 f1 21 c6 58 4e 74 ff
        session_id[32]=
          81 98 54 07 4c 14 b2 37 d6 13 05 26 05 5f bc dd
          46 5c d6 aa 9e ee 20 22 3e 13 7b 98 13 d0 30 ee
        cipherSuite         TLS_RSA_WITH_3DES_EDE_CBC_SHA
        compressionMethod                   NULL
1 3  0.0005 (0.0000)  S>CV3.1(1278)  Handshake
      Certificate
1 4  0.0005 (0.0000)  S>CV3.1(160)  Handshake
      CertificateRequest
        certificate_types                   rsa_sign
        certificate_types                   dss_sign
        certificate_types                 unknown value
        certificate_authority
          30 81 8d 31 0b 30 09 06 03 55 04 06 13 02 55 53
          31 0b 30 09 06 03 55 04 08 13 02 43 61 31 11 30
          0f 06 03 55 04 07 13 08 53 61 6e 20 4a 6f 73 65
          31 1b 30 19 06 03 55 04 0a 13 12 50 61 79 50 61
          30 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 70
          76 6f 69 63 75 40 70 61 79 70 61 6c 2e 63 6f 6d
      ServerHelloDone
1 5  0.0008 (0.0003)  C>SV3.1(2)  Alert
    level           fatal
    value           unknown_ca
1 6  0.0130 (0.0121)  C>SV3.1(67)  Handshake
      ClientHello
        Version 3.1
        random[32]=
          4e d8 a4 ee 61 a7 5b 6c 64 89 61 fb cf 0a a2 85
          65 04 40 47 23 0d 62 35 b4 59 b5 bb 2e b7 a8 22
        cipher suites
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        TLS_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_AES_128_CBC_SHA
        TLS_RSA_WITH_IDEA_CBC_SHA
        TLS_RSA_WITH_RC4_128_SHA
        TLS_RSA_WITH_RC4_128_MD5
        compression methods
                  NULL
*1 7  0.0130 (0.0000)  C>SV3.1(2)  Alert*
*    level           fatal*
*    value           unexpected_message*
1    0.0130 (0.0000)  C>S  TCP FIN
1 8  0.0131 (0.0001)  S>CV3.1(74)  Handshake
      ServerHello
        Version 3.1
        random[32]=
          4e d8 a4 ee 42 58 23 7f 51 e4 c1 10 b6 9d f0 7e
          25 bd 8a 95 3c e2 dd 0e 4d 3e 61 38 33 2b a9 58
        session_id[32]=
          5b ca 68 de 2f 18 cb 03 df 8b 23 b9 b0 19 87 7e
          02 72 f7 bb e2 a5 21 6a 7e c8 a8 38 12 83 d8 fe
        cipherSuite         TLS_RSA_WITH_3DES_EDE_CBC_SHA
        compressionMethod                   NULL
1 9  0.0131 (0.0000)  S>CV3.1(1278)  Handshake
      Certificate
1 10 0.0131 (0.0000)  S>CV3.1(160)  Handshake
      CertificateRequest
        certificate_types                   rsa_sign
        certificate_types                   dss_sign
        certificate_types                 unknown value
        certificate_authority
          30 81 8d 31 0b 30 09 06 03 55 04 06 13 02 55 53
          31 0b 30 09 06 03 55 04 08 13 02 43 61 31 11 30
          0f 06 03 55 04 07 13 08 53 61 6e 20 4a 6f 73 65
          0c 06 03 55 04 0b 13 05 49 6e 66 72 61 31 0f 30
          0d 06 03 55 04 03 13 06 70 76 6f 69 63 75 31 20
          30 1e 06 09 2a 86 48 86 f7 0d 01 09 01 16 11 70
          76 6f 69 63 75 40 70 61 79 70 61 6c 2e 63 6f 6d
      ServerHelloDone

Any help whatsoever to solve this will be highly appreciated.

Thanks,
handshak3

On Fri, Dec 2, 2011 at 3:42 AM, Jakob Bohm <[email protected] <mailto:[email protected]>> wrote:

    On 12/1/2011 6:33 PM, Rohit Bansal wrote:

        Hi,

        Let me start with a disclaimer that i am not very experienced
        with openssl.

        I have a requirement. In an enterprise all clients and servers
        communicate over ssl. the certs in client and server are self
        signed.
        There is one client application which talks to 100+ different
        services.

        Currently the peer verification is done using a single file
        containing all those self signed certs on client side.
        if (!SSL_CTX_load_verify_locations(context,
        trusted_certs_filename, NULL))
        fprintf(stderr,"SSL_CTX_load_verify_locations failed
        (file:%s)", _trusted_ca_certs_filename.chars());

        // client always receives a certificate from the server, and
        if that
        // certificate fails to verify, the handshake will be terminated
        SSL_CTX_set_verify(context, SSL_VERIFY_PEER, NULL);

        As the pem file in question contains 100+ certs, ssl context
        initialization takes a while. My task is to migrate that to
        using CA Path.I have a solution but also want to build a fall
        back mechanism

        I want to fallback on initializing the context with the pem
        file in case the cert verification fails with CA Path.

        At high level i see following to be done
        - on client handle the reason code
        SSL_R_CERTIFICATE_VERIFY_FAILED from SSL_connect
        - on server handle the reason code
        SSL_R_TLSV1_ALERT_UNKNOWN_CA from SSL_accept
        - change the ssl context to have pem file as verified certs on
        client side.
        - renegotiate ssl handshake over the same socket

        Does anybody of the users know of such implementation or its
        feasibility? Please help me to give some ways to solve this issue

        Regards,
        banro21

    Here is another possibility:

    1. Add your own verification callback, which should then be called
    when OpenSSL tries to
    verify that self-signed cert.

    2. In your callback, manually try both verification methods before
    deciding if the result returned
    to the SSL code should be "valid" or "invalid".

    3. The "Manual" code in the callback can presumably reuse the
    existing OpenSSL functions
    to do the verification, the point is that you get a chance to
    intercept the result before it
    reaches the SSL layer.

    This way you won't get into the whole "renegotiate on a failed
    connection" issue.

    ______________________________________________________________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List [email protected]
    <mailto:[email protected]>
    Automated List Manager [email protected]
    <mailto:[email protected]>




--
Rohit Bansal

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [email protected]
Automated List Manager                           [email protected]

Reply via email to