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 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 authorities (which fall under the CA/B Forum remit), but not certificates from enterprise certificate authorities (i.e. private certificate authorities). This may however change given how operating systems handle certificates and often (falsely) assume that certificate use is limited to the web.
This will, if you do not employ certificate renewal automation via a mechanism like SCEP or ACME/CertBot, increasingly cause administrative and technical issues for you. Consider looking at SCEP, ACME or CertBot, and you should also consider support for any of these methods for automated certificate renewal to be an important criterion when choosing a commercial CA.
What does this mean for eduroam?
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 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 for your eduroam server certificate, all devices configured with proper server certificate validation for the old certificate authority 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 authority!
So, if you choose a certificate authority 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 will.
This topic is still under construction.
More information
See the CA/Browser Forum's vote here: 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)
Universiteit Twente (Netherlands) has some advice here: Automate your certificate management with ACME and SURF certificates
The GÉANT TCS has a timeline of changes here: HARICA TCS Updates
The Jisc Certificate Service has this link: Security certificate automation