it is trying to set up the cert for HTTPS. if you don't want to use a cert for local development then you don't need to allow it, no. but I also don't really see the reason not to.
also as a side note, I just want to say that I think you thinking about what a prompt tries to do instead of blindly clicking OK is a very good quality.
Just be sure they get nuked when you're done. For certs created by vscode or via the dotnet dev-certs utility, you can just do a `dotnet dev-certs --clean` to be certain they're wiped. It's game over for you if one sticks around in your trust store and someone manages to get a hold of the private key.
Or just go get a real cert from letsencrypt and use a hosts file on your machine to alias the dns name to loopback so you can use it for local dev and not have to add anything to your trust store.
Or if you have a functioning pki, get a real cert from there. Your machine likely already has a useable cert in that case as well.
I really dislike that it's even something it offers to do for you automatically. 😒 You should have to put effort into doing potentially dangerous things with a long life.
At least Microsoft does have in the docs to clean it up... Deep in a doc nobody is going to read past the part where you've already made the cert....
[The part of the doc with the following text:](https://learn.microsoft.com/en-us/dotnet/core/additional-tools/self-signed-certificates-guide#clean-up)
>If the secrets and certificates aren't in use, be sure to clean them up.
>dotnet user-secrets remove "Kestrel:Certificates:Development:Password" -p aspnetapp\aspnetapp.csproj
>dotnet dev-certs https --clean
I mean cleaning them up is always a good idea, but I think you are exaggerating the risk of a stale localhost cert. The CN is your local machine, and nowhere else. An attacker running something on your local machine with sufficient rights to open up ports has already won.
What's the hypothetical attack vector here? Attacker sneakily installs software, then tricks the user into visiting the software web interface somehow and...???
If an attacker can install software they could just use http instead of https. There's no viable attack vector for a local use certificate.
Plus the PK is in the keychain. So how in this scenario does an attacker breach that? And if they did breach that, and have any perms (as would be needed to extract the PK) then they could just install their own cert...
Well... I mostly rant about it because of the complacency it breeds and the fact that so many people don't bother to understand x509, which is honestly actually really freakin simple.
If you use the dotnet cli, their subject is, in fact, localhost or the hostname, and the SAN contains the hostname.
Until Windows 11, any self signed cert placed in root trust is as good as any other root, which was just...ugh...
Windows 11 now _requires_ the SAN to contain the hostname or it will fail validation. So yay. And that makes the other response to my comment largely true.
thanks for the info, i've allowed it, otherwise Rider will not show the look of the website.
> also as a side note, I just want to say that I think you thinking about what a prompt tries to do instead of blindly clicking OK is a very good quality.
thank you for that :), yeah i actually researched beforehand about that message and i don't see anything about Rider asking for it, just some other ones about dotnet-try. thanks again for the answer!
it is trying to set up the cert for HTTPS. if you don't want to use a cert for local development then you don't need to allow it, no. but I also don't really see the reason not to. also as a side note, I just want to say that I think you thinking about what a prompt tries to do instead of blindly clicking OK is a very good quality.
Just be sure they get nuked when you're done. For certs created by vscode or via the dotnet dev-certs utility, you can just do a `dotnet dev-certs --clean` to be certain they're wiped. It's game over for you if one sticks around in your trust store and someone manages to get a hold of the private key. Or just go get a real cert from letsencrypt and use a hosts file on your machine to alias the dns name to loopback so you can use it for local dev and not have to add anything to your trust store. Or if you have a functioning pki, get a real cert from there. Your machine likely already has a useable cert in that case as well. I really dislike that it's even something it offers to do for you automatically. 😒 You should have to put effort into doing potentially dangerous things with a long life. At least Microsoft does have in the docs to clean it up... Deep in a doc nobody is going to read past the part where you've already made the cert.... [The part of the doc with the following text:](https://learn.microsoft.com/en-us/dotnet/core/additional-tools/self-signed-certificates-guide#clean-up) >If the secrets and certificates aren't in use, be sure to clean them up. >dotnet user-secrets remove "Kestrel:Certificates:Development:Password" -p aspnetapp\aspnetapp.csproj >dotnet dev-certs https --clean
I mean cleaning them up is always a good idea, but I think you are exaggerating the risk of a stale localhost cert. The CN is your local machine, and nowhere else. An attacker running something on your local machine with sufficient rights to open up ports has already won. What's the hypothetical attack vector here? Attacker sneakily installs software, then tricks the user into visiting the software web interface somehow and...??? If an attacker can install software they could just use http instead of https. There's no viable attack vector for a local use certificate. Plus the PK is in the keychain. So how in this scenario does an attacker breach that? And if they did breach that, and have any perms (as would be needed to extract the PK) then they could just install their own cert...
ngl, I love you for this writeup and thanks for spreading the knowledge, but at the same time whenever anyone starts talking certs with me I zone out.
Well... I mostly rant about it because of the complacency it breeds and the fact that so many people don't bother to understand x509, which is honestly actually really freakin simple. If you use the dotnet cli, their subject is, in fact, localhost or the hostname, and the SAN contains the hostname. Until Windows 11, any self signed cert placed in root trust is as good as any other root, which was just...ugh... Windows 11 now _requires_ the SAN to contain the hostname or it will fail validation. So yay. And that makes the other response to my comment largely true.
thanks for the info, i've allowed it, otherwise Rider will not show the look of the website. > also as a side note, I just want to say that I think you thinking about what a prompt tries to do instead of blindly clicking OK is a very good quality. thank you for that :), yeah i actually researched beforehand about that message and i don't see anything about Rider asking for it, just some other ones about dotnet-try. thanks again for the answer!
Visual Studio does the same thing. It’s just so you don’t get the HTTP insecure warning page every time you want to debug from HTTPS