Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Given the current trend by the CA/Browser Forum drive to progressively shorten certificate lifetimes for security reasons, the question of how to handle certificate renewal and automation becomes ever more urgent. As of Q1 2025, all public certificate authorities (CAs) have committed to follow the CA/B Forum's recommendation to reduce server certificate lengths progressively to 47 days within the next few years.

This generally affects web services, but for eduroam this is just as relevant, since certificates are an integral part of many EAP methods usable within eduroam. Currently the automation affects certificates that are signed by public certificate authoritiesCAs (which fall under the CA/B Forum remit), but not certificates from enterprise certificate authorities CAs (i.e. private certificate authoritiesCAs that cannot be validated by the browsers/devices by default). This may however change given how operating systems handle certificates and often (falsely) assume that certificate use is limited to the web. 

...

Those who simply allow their users to tap on the eduroam network to connect without using a tool like the eduroam CAT website or the geteduroam app will need to be aware that their users will be prompted to accept a new certificate when your certificate rolls over. This may not be entirely user friendly. Using a properly configured CAT profile (or profile from an equivalent tool) that correctly configures server certificate validation (which is what CAT profiles do) can make that a non-issue since the certificate's certificate authority CA root certificate is used to verify the server certificate's validity, along with the common name of the certificate.

However, this comes with the caveat that should you choose to change your certificate authority CA for your eduroam server certificate,   all devices configured with proper server certificate validation for the old certificate authority CA will fail to authenticate, unless a transition period is implemented where the devices are configured to accept certificates from the old and the new certificate authorityCA

So, if you choose a certificate authority CA like Let's Encrypt (which has implemented automation from the beginning), stick to it, and your users with devices correctly configured with server certificate validation will never know that the server certificate rolls over every month, while those who just tapped on the network to connect connect will.


Warning
This topic is still under construction. 


More information

See the CA/B Browser Forum's vote here: https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/ Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (13 May 2025)

Communications from Sectigo: CA/Browser Forum passes ballot to reduce SSL/TLS certificates to 47 day maximum term, endorsed by Sectigo (14 April 2025)

Communications from DigiCert: TLS Certificate Lifetimes Will Officially Reduce to 47 Days (16 May 2025) https://www.sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-daysCommunications from DigiCert: https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days

Universiteit Twente (Netherlands) has some advice here: Automate your certificate management with ACME and SURF certificates

...