Bug #6453
closed
Auto-created certs not updated as needed by system, nor viewed/fixed easily by user
0%
Description
I happened to be checking the certs on my router, and noticed the main webconfigurator cert was 1024 bits, which has been considered unsuitable for a few years. The reason was that it was created under pfSense 2.0.x, which used 1024 bit certs and 2000 day lifetime. In 2.1 this was upgraded to 2048 bits but system_webgui_start() only checks for existence, it doesn't check for minimum acceptability. Therefore 2.1 new install had a 2048 bit key but 2.0 upgraded to 2.1 kept an outdated key size and a lifespan of about 5.5 years.
The user, even if they notice this, can't easily fix it through the certificate manager because there isn't an obvious way to delete, revoke, or regenerate a problematic non-user-created cert (the inbuilt CA doesn't appear in the revocation page either so the old cert can't be added there). I don't know if the same issue would arise with a compromised system-generated cert but I suppose it could.
As I don't know whether the web configurator is sensitive to deletion or change of its certificate (eg before it is started), and I don't know what other certs might have similar problems, I'm redmining this instead. It raises several questions:
- Key size adequacy for system-created certs probably needs checking explicitly during config upgrades (like any other old data detected when config.xml is brought up to the latest version), since that's when new key specs would be amended in the codebase anyway;
- There's also a bit of a concern whether the system correctly exires and recreates old system-created certificates. For example, suppose I wait 5 years, would the web configurator be unable to use the current cert (due to valid_to timeing) but also not replace it with a new one (since the one time it checks, it would find an existing cert but not realise it's out of date). Does this happen on any other certs? Should there be a cron job 24 hourly, to check for expired system-generated certs and make sure action is taken on them when they expire?
- It would be helpful if users have a way to view all certs and CAs in cert manager. As well as transparency, it would allow the user to manage/regenerate/revoke system-generated certs as easily as user-created certs.
- Last, is 2000 days a sensible lifetime for any "invisible-to-user" system certificate? Encryption can move on quite fast and perhaps 1 - 2 years is enough?
To help this along, I've added a function to return the key size of a cert, (https://github.com/pfsense/pfsense/pull/2994) as this is useful anyway and would be needed here.
Updated by Jim Pingle about 9 years ago
- Status changed from New to Rejected
The problem, as stated, is not a good idea, but could be handled better in a few separate tasks and not this directly. Automatically regenerating any certificate would not be a good practice. At best it's a POLA violation and at worst it could clobber someone's custom certificate and break access to the GUI in one way or another. The old one may be insecure but we can't know if that was a deliberate choice by the admin or not. They may have to deal with some old/insecure browser that we have no control over. Breaking access to the GUI doesn't help there.
You can easily regenerate and activate a fresh GUI cert using the PHP shell:
pfSsh.php playback generateguicert
You say "It would be helpful if users have a way to view all certs and CAs in cert manager" but all certificates are shown in the cert manager, even the automatic GUI cert. Nothing is hidden. It's right there in the list. It may not show all properties of the cert (key length, etc) but there is only so much room on the page. It might be nice to have a "cert info" link to follow that showed a full OpenSSL dump of the cert properties, but that's a different problem.
I've tried several different ways to regenerate certificates by initiating the rebuild in the browser with a button/link but it's mishandled in weird ways by each browser when the cert changes between requests, and often prompts to resubmit the request which would keep happening over and over. It's a tricky situation without a quick answer. Maybe a batch process that happened in the background after a few minutes of waiting to ensure the user's browser doesn't fall into a trap, but even then I'm not sure how well it might be handled. Perhaps a "Generate new GUI certificate next reboot" might be OK, but I hate implying that a reboot is necessary, even if it would make the process smoother. Generating it manually from the shell is the best way at the moment.
The lifetime of a cert in the context of the GUI has little bearing on reality in the way you imply. If we set the cert to expire, and then it does expire, the user could be locked out of the GUI with no way back in. That does not help the user to make a new certificate. They would have to know about it beforehand and make a new cert before the expiration. Moving up the expiration time doesn't actually help accomplish that, it just makes a heavy-handed attempt to punish them if they don't. Needs more carrot, less stick.
The most I could see happening here is a gentle reminder that the certificate is old/insecure/etc and offering a nudge to rebuild it. Not even a full notification as that could be annoying if it was a deliberate choice. Maybe an info panel inside the system info widget that has a permanent "dismiss until gui cert changes" action, but that would be a completely different feature request.
Updated by Stilez y about 9 years ago
Useful and detailed answer.
One way to resolve it that your comment almost suggests but doesnt. Itr sounds like the issue is not that the server would need a reboot to redo the cert ("generate new GUI cert next reboot"). It's that the session handling would get fubar'd, and the browser's handling would become unpredictable at best, looping and failing at worst. Solution surely - let the user confirm that this will terminate the user session, and all users will have to log back in after the new cert is created, and "press OK to regenerate the GUI certificate". Then ensure the GUI redirects to a static page and the session data is deleted at both ends (much like a logoff). Logoff doesn't loop when it kills the session and forces a new login, so new cert should be able to do something similar.
Alternatively, perhaps it generates the new cert in the background, so that updating will be very fast (not needing generating as well) when it's able). Then condition a cert replacement on "next time the system notices there are no logged in GUI sessions", at which time the cert can be automatically updated without disruption in a fraction of a second.
Of course it can also gently nudge via the ticker and also via notifications.
So suggested approach would be -
- Notice GUI cert running out, maybe a week in advance.
- If it's a system generated cert (it has the usual params for autogenerated cert) we add a ticker and notification to remind the admin. We also run a check periodically and on every restart of the GUI, and also at each occasion a session ends. Last, we generate a new cert to replace the old one, and save it as "pending_gui_cert" or something similar, in $config.
- At any time that one of these checks notices there are no logged in GUI sessions, it swaps the pending_gui_cert into the actual gui cert, and the original gui cert into "expired_gui_cert" (so the admin can view if desired). This takes a fraction of a second, so even a logout and immediate login allows the certs to be updated transparently without affecting on any user experience and without reboot.
Any use?