Hi Frank,

As others have already replied, a TLS connection is not limited by the
certificate used to authenticate the server (if any). More generally,
the connection is not bound to the certificate. Once the handhsake is
over, the client does not need to remember how it verified the server's
identity.

Mbed TLS does not keep the handshake data (including certificates) after
the handshake is over, and does not have any mechanism to automatically
close a connection after a given amount of time. If you want to renew
the server authentication periodically based on the certificate, you
would need to set up a callback to read the certificate data with
mbedtls_ssl_set_verify() and call mbedtls_ssl_close_notify() when you
want to stop using the connection. (Renegotiation instead of a new
connection might be an option in TLS 1.2.) Please note that I find this
a weird requirement and I would push back on it. If you want to
re-authenticate the server regularly, I suggest closing the connection
when idle or regularly based on a client-side policy, and not linking
this to the server management policy of certificate renewal.

Regarding private struct members, we've identified the loss of knowledge
about the state as a problem in some applications. We've decided not to
add a getter for the state, because the states are tricky to use, do not
take renegotiation into account in TLS 1.2, and are different between
TLS 1.2 and 1.3. See the discussions in
https://github.com/Mbed-TLS/mbedtls/issues/5331 and
https://github.com/Mbed-TLS/mbedtls/issues/4383 . Instead we're adding
new callbacks and new functions such as mbedtls_ssl_is_handshake_over(),
which will be in the next release (no date set yet). For p_bio, it's
just the value set by mbedtls_ssl_p_bio so I don't understand why an
accessor would be useful. If your application has multiple SSL contexts
and you want to tie an SSL context to application data structures, the
user data pointer (mbedtls_ssl_set_user_data_p(),
mbedtls_ssl_get_user_data_p()) (also to be in the next release) may be
useful.

If you have a use case for accessing structure fields which is still not
covered in the development branch or by an open issue
(https://github.com/Mbed-TLS/mbedtls/issues), especially those in the
Mbed TLS 3.2 epic
(https://github.com/orgs/Mbed-TLS/projects/1#column-18338314), please
open an issue on GitHub and let us know what you need and why.

Best regards,

--
Gilles Peskine
Mbed TLS developer

On 25/04/2022 12:47, Frank Bergmann via mbed-tls wrote:
> Hi all,
>
> I have some questions.
>
> 1) If you have an established TLS connection (mbed TLS 3.x) and while the
> connection is up the (server-) certificate expires: Will the connection stay
> up? Or is a new handshake (with valid cert) REQUIRED?
>
> 2) Related to question 1: CAN mbed TLS switch to a new cert on an existing
> TLS connection? (e.g. by doing another handshake from server OR client side)
>
> 3) With 3.x some struct members are now "private". Even if you can allow
> private access by a define it would be better to use a getter. But for ssl
> context's "state" I am missing this and also for "p_bio" (to access fd). Is
> there a chance to get this implemented?
>
> BTW - a big "LIKE" for 3.x! I really appreciate the changes. Thank you!
>
> kind regards,
> Frank
>

--
mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org
To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org