Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. How to get access to OpenSSL context?
QtWS25 Last Chance

How to get access to OpenSSL context?

Scheduled Pinned Locked Moved General and Desktop
5 Posts 2 Posters 2.1k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T Offline
    T Offline
    The C factor
    wrote on last edited by
    #1

    Hi,

    I need to do some custom OpenSSL processing and I need the OpenSSL context associated to a QSslSocket. Are there any ways to get to the context? Or also vice versa, If I create an OpenSSL context, is there a way to pass it to a QSslSocket?

    The only piece of information I was able to find is https://bugreports.qt-project.org/browse/QTBUG-14983 which talks about an internal QSslContext that will be available in 5.1.0. So it seems to me that, since it is internal, I will not gain a lot from 5.1.0....

    Before I dig in the Qt code or build my own Qt 5 off the git repo, anybody has an idea?

    thanks :-)
    marco.m

    1 Reply Last reply
    0
    • R Offline
      R Offline
      rich
      wrote on last edited by
      #2

      You're right that currently the context is a private class. There's no API that allows you to access it. Could you tell me what you're trying to do with it as there may be an alternative solution.

      1 Reply Last reply
      0
      • T Offline
        T Offline
        The C factor
        wrote on last edited by
        #3

        Hey Rich,
        I wanted to register a callback with SSL_CTX_set_verify(SSL_CTX *ctx, int mode, int (*verify_callback)(int, X509_STORE_CTX *)). This callback allows you to do custom/additional verification of the peer certificate.

        After thinking a bit about it, I realized that I can obtain the same by connecting to two QSslSocket signals: sslErrors() (on TLS handshake failure) and encrypted() (on TLS handshake success). A decent workaround I think.

        Thanks anyway for your offer to help :-) I assume you are the Rich that wrote a few blog posts on Qt and OpenSSL, right?

        There is another feature that is missing I think: validating that a private key and the public key of a certificate match. Today the code does the validation too late, when connecting (client side) or when receiving a connection (server side). Especially on the server side, you want to know upfront that your configuration is wrong, instead of waiting for the first client attempting to connect :-)

        I think the cleanest way would be to provide an accessor to the public key from the private key:

        QSslKey private(...)
        QSslCertificate cert(...)
        if (private.publicKey() != cert.publicKey()) {
        // wrong key pair...
        }

        what do you think?

        1 Reply Last reply
        0
        • R Offline
          R Offline
          rich
          wrote on last edited by
          #4

          bq. After thinking a bit about it, I realized that I can obtain the same by connecting to two QSslSocket signals: sslErrors() (on TLS handshake failure) and encrypted() (on TLS handshake success). A decent workaround I think.

          Yes, the encrypted() signal happens immediately after the handshake is complete, so you can do additional processing there. I've added the same signal to QNetworkAccessManager in Qt 5.1 to support exactly this use-case.

          bq. Thanks anyway for your offer to help :-) I assume you are the Rich that wrote a few blog posts on Qt and OpenSSL, right?

          Yes, that's right/

          bq. There is another feature that is missing I think: validating that a private key and the public key of a certificate match. Today the code does the validation too late, when connecting (client side) or when receiving a connection (server side). Especially on the server side, you want to know upfront that your configuration is wrong, instead of waiting for the first client attempting to connect :-)

          bq. I think the cleanest way would be to provide an accessor to the public key from the private key:

          bq. QSslKey private(…)
          QSslCertificate cert(…)
          if (private.publicKey() != cert.publicKey()) {
          // wrong key pair…
          }

          bq. what do you think?

          Yes, that seems like a sensible thing to support. Do you think you could file a bug report for it so that it gets added to the todo list (it will avoid it being missed).

          1 Reply Last reply
          0
          • T Offline
            T Offline
            The C factor
            wrote on last edited by
            #5

            Done, "QTBUG-31815":https://bugreports.qt-project.org/browse/QTBUG-31815

            1 Reply Last reply
            0

            • Login

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups
            • Search
            • Get Qt Extensions
            • Unsolved