An IoT device using mutual TLS can have a long running TLS connection to a server, during which time its client certificate could expire or be revoked. When that happens should the server notice and terminate the connection?

  • I think there is no simple answer just based on the information provided in the question. It depends on why the certificate was revoked, what are the implication for the existing connection if the certificate was revoked, if revocation is still done if the certificate is already expired, how well the private key is protected in the first place (i.e. software only or cannot be copied since hardware backed) ... Commented Mar 8, 2023 at 7:02
  • One thing is that each device will have a unique private key stored in a secure element, so the certificate for that is unique and not shared across devices. Commented Mar 8, 2023 at 17:17
  • "private key stored in a secure element," - which means that certificate revocation due to a stolen private key should usually not happen, since the key should hopefully not be extractable from the device. The question is therefore - what reasons there might be for certificate revocation in your case? I could imagine if the device itself was stolen (i.e. including the hardware-secured key), but ohers? And in which case the certificate could expire - apart from broken processes to reissue new certificates on time? Still too much details missing about the details of your use case. Commented Mar 8, 2023 at 18:26

2 Answers 2


What needs to be done depends on what the certificate is used for. If the certificate is just used to provide some binding to the device where the certificate is installed, then it is sufficient to check authentication only at the beginning of the TLS session, since the TLS session cannot simply be transferred to another device.

If the client certificate is instead used to authenticate the client similar to login credentials, then there might be some re-authentication needed for critical actions. This is similar on how re-entering the credentials is required with other authentication methods. Re-validating a certificate in this case is tricky though. Even if it is not expired one would need to check that it is was not revoked in the meantime. And if it is expired one needs to request a new certificate, i.e. close the current TLS session and let the client create a new one - hopefully with the new certificate.


Under normal circumstances, certificate expiration and revocation have different semantics and require different handling.

In the case where an IoT device connects to the server with a valid TLS certificate, you know that the device is legit. If, during the connection, the certificate expires then the device's identity is not invalidated. Which means that the server can keep receiving data from the device until the connection is closed for a reason.

However, if (at the same scenario) the device's certificate is revoked, then this may signify that the certificate has been stolen and that a rogue device is using it. In this case, the server should terminate immediately the connection (and probably question the data received by that device - but, that's another story).

As you can understand, the two cases require different design and setup; whereas with the certificate expiration there's nothing that the server needs to do (just wait until the current connection is dropped), with the certificate revocation the server should be notified (or the revocation list should be polled by the server - whatever fits your requirements) and it should drop immediately the connection.

Note that the analysis above assumes that each device has its own certificate and that no two devices can use the same device to authenticate with the server. This implies that a rogue device cannot operate simultaneously with a legit one, given that the rogue device would use the legit's compromised certificate. Things differ when you have group certificates, i.e. certificates that can be used by more than one device. In this case, a rogue device is just one more device in the group, which means that in order to narrow the window of opportunity, the server will have to detect the cert expiration and drop all connections, forcing each device to re-authenticate.

  • 1
    The point of expiration is that you don't need revocation anymore after the certificate is expired. Thus you cannot count on still getting useful revocation information once the certificate got expired. Insofar you must assume that an expired certificate is compromised since you can no longer prove otherwise. Commented Mar 7, 2023 at 20:13
  • @SteffenUllrich ah, you mean after a certificate is expired then there can't be any revocation? Yes, indeed. However my point is that the IoT device will use the cert for authentication during the TLS handshake only. At that point the cert is valid. Then the shared secrets will be used to communicate, which the server assumes that only the legit device has them. If the cert is expired, it cannot be used again to establish a new connection but this does not invalidate the identity of the already authenticated device
    – user284677
    Commented Mar 8, 2023 at 6:28
  • @SteffenUllrich if it's revoked, however, then we suspect a problem with it. But because we don't know when the problem appeared in the first place (we only know when we found out about it, hence we revoke it) then we assume that all the currently established connections are potentially invalid (i.e. that the cert was compromised before all current connections were established and, as such, all current connections are illegit). In this case, the server has to be notified to drop all connections established with that cert. Does that address your remark?
    – user284677
    Commented Mar 8, 2023 at 6:28
  • Assuming the certificate is valid from 00:00 to 5:00. The connection gets established at 1:00 and is still ongoing at 7:00, i.e. way after certificate expiration. The certificate gets compromised at 4:00, but the compromise is only realized at 6:00, i.e. after expiration. The certificate will not be revoked since it is no longer valid anyway at the time the compromise was realized. Commented Mar 8, 2023 at 6:36
  • 1
    I made a comment to the question that the scenario is not clearly defined enough to provide a good answer. There are more information needed to decide on how to properly deal with the situation. Commented Mar 8, 2023 at 7:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .