Yea, I'm still on the hunt for a better way to solve my primary problem: detect an acme-tls/1 ALPN protocol request during the TLS handshake so that I can swap out the context to one with the cert chain that Let's Encrypt is expecting to see.

It seems like OpenSSL provides three primary hooks into the handshake: ClientHello, servername, and ALPN. The servername callback is the only one that can be "officially" customized by Python's SSL API. The ALPN callback seems to be used under the hood to implement SSLContext.set_alpn_protocols() but there isn't a way to specify complete control of the callback.

My current "hack" is to use the SSLContext._msg_callback to check for the acme-tls/1 protocol explicitly:

def msg_callback(conn, direction, version, content_type, msg_type, data):
    if direction == 'read' and b'acme-tls/1' in data:
        print('got an acme-tls/1 request')
        print('set a flag for sni_callback to check, etc etc')

I know this probably isn't a good or safe way to solve the problem. The current docs make it sound like sni_callback would be my one-stop shop but that ended up not being the case. Maybe I could subclass SSLSocket, override do_handshake(), and then swap out the context before or after super().do_handshake()? I'm quite new to Python/OpenSSL internals so I'm not sure if that is even possible. Can a context be swapped out so late in the handshake process?

The SSL_client_hello_get0_ext() function you mentioned could be a contender. The _msg_callback I'm currently using _does_ do the trick but maybe shouldn't be documented and made official? Regardless of how best to solve my current acme-tls/1 ALPN detection issue, the sni_callback won't ever be the full answer unless some internal mechanics are added to watch ClientHello and preemptively peek at the requested ALPN protocol(s).