You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After thinking about it, I don't think there's any usecase where you might prefer a project scoped certificate compared to a shared certificate 🤔... I mean, the only downside I see is that the certificate may remain somewhere in your system even after you delete all your js projects.
So I think it might be better to just create a shared certificate anyway.
sometimes you want to create a local certificate for a custom test domain, not localhost (some features in some browsers only work with the "green ssl lock" and you can't always get that for localhost)
So application specific certificates have a usecase.
Either way you should ensure that
a) the cert is limited in scope as much as possible
b) stored in a secure location with limited access rights to the user only
c) added to the os/browser chains only for ssl purposes and only after user confirmed this is ok
d) if you have to add the root ca to the os chain to achieve "green lock", throw away the key to that CA immediately
The goal of all this is that it is impossible to use this devtool to compromise the developer by getting access to a trusted ca and presenting them with a fake site that looks legit.
So after talking a bit with @userquin, I suggest adding two features:
The first time the plugin is launched in a project, as the user where he wants to generate the certificate:
If the user chooses the shared certificate, ask him if he wants to install it
I can work on this feature.
The text was updated successfully, but these errors were encountered: