javiercn commented 3 years ago

Related Epic #41990

The different flavors of Linux are the only place where --trust is not supported for dotnet dev-certs. We had an issue on openssl blocking this in the past that prevented dotnet-to-dotnet trust. Now that the issue has been solved and that distros are updating their openssl versions to newer versions without the original issue that was blocking us, we can consider adding support for trust across supported distros.

Our support Matrix looks as follows (taken from here):

OS	Version
Alpine Linux	3.13+
CentOS	7+
Debian	10+
Fedora	32+
OpenSUSE	15+
Red Hat Enterprise Linux	7+
SUSE Enterprise Linux (SLES)]	12 SP2+
Ubuntu	16.04, 18.04, 20.04+

Open SSL status across versions

OS	Version	Open SSL Version on latest OS version
Alpine Linux	3.13+	1.1.1k (on 3.13)
CentOS	7+	1.1.1d (on 8.3)
Debian	10+	1.1.1k (on 11)
Fedora	32+	1.1.1k (on 34)
OpenSUSE	15+	1.1.1d (on 15.2)
Red Hat Enterprise Linux	7+	TBD
SUSE Enterprise Linux (SLES)]	12 SP2+	1.1.1d (on latest, based on assumptions from OpenSUSE)
Ubuntu	16.04, 18.04, 20.04+	1.1.1k (on 21.04)

For the distros that don't meet the openssl version requirement, a new openssl version can be installed in most cases (at the users risk/judgement), either from an existing package available for the distro or downloading openssl and compiling it from source. I validated this across a few distros as follows:

Ubuntu: 21.04 already contains a new enough version.
Fedora: 34 already contains a new enough version.
Alpine: 3.13 already contains a new enough version.
CentOS: Installed open SSL by adding fedora 34 as a yum source and getting it from there.
OpenSUSE: There is an experimental package available for 1.1.1k in Open SUSE 15.2
SLES: I haven't tried, however I suspect the same package used for OpenSUSE works.
Debian: Tried with Bullseye which is on Hard Freeze and will be released likely this year. I only had to setup the apt sources for it to work. It already contains a new enough version.
RHEL: There's no way to download an ISO (AFAIK) without registering, which I don't want to do. I suspect the same I did on CentOS will work here.

Each distro that we want to support should be considered to have the cost of supporting and maintaining entire new OS, since we have to support specific environment variations and test functionality on each of them.

For each distro we need to support:

--clean to remove the trusted certificates.
--check to determine if the certificate is trusted in all the places we care about
- Firefox
- Edge/Chrome
- dotnet runtime
--trust to apply the necessary changes in the environment to make the certificate trusted.

In addition to that, we need to make sure that all the tools and libraries we need are present on the OS, have the right version and are available on the path:

openssl (with a version equal or higher than 1.1.1h)
libnss3-tools (check for the presence of certutil)
firefox (check for firefox --version on the path)
edge (check for microsoft-edge --version)
chrome (check for google-chrome --version)

For each distro we need come up with a list of instructions to setup the machine and create a VM image we can leverage for regression testing. We need to capture the instructions for doing the following:

Install the base OS
Install Edge
Install Chrome
Install dotnet
Install new enough openssl version (if necessary)
Install libnss3-tools (certutil)

Prepare the VM to be shared with the team (we should be able to do so as described here

Once all the software is installed on the given distro, --trust, --check, --clean must work on 3 areas:

Firefox: Can be configured via an enterprise policy or via certutil, we need to determine the best way to do this. The user profile is in `~/,mozilla and we can find the default there.
Edge/Chrome: Can be configured via certutil at ~/.pki/certificates
dotnet runtime: Can be configured by dropping the certificate in the openssl folder.

Operation/Component	Firefox	Edge/Chrome	dotnet runtime
`--check`	look for a policy and a certificate in the right folder or use certutil against the profile database to ensure the right cert is trusted	use certutil against the profile database to ensure the right cert is trusted	check for a certificate file with the name `aspnetcore-localhost-https-{sha256-certificate-hash}.pem` in the openssl certificates folder
`--trust`	either install an enterprise policy on the user profile or use certutil to modify the trust database for the profile db	use certutil to modify the trust database	export the certificate to a file in PEM format; copy the certificate to the openssl certificates directory with `aspnetcore-localhost-https-{sha256-certificate-hash}.pem`
`--clean`	remove the enterprise policy and all certificates starting with `aspnetcore-localhost-https-` or use certutil to remove all certificates that match `aspnetcore-localhost-https-` from the profile database	use certutil to remove all certificates that match `aspnetcore-localhost-https-` from the database	remove all certificates that match `aspnetcore-localhost-https-` from the openssl certificates directory.

There are slight variations that we need to account for across distros. Ideally we don't want those things to show up in our code, since it will create a hard to maintain mess. To that matter, we will create a manifest for each distro/version with all the important details about the distro to drive all the operations and embed them in the dev-certs assembly.

When a command is run on Linux, we will try and recover the manifest by convention (<<distro>>.<<version>>.manifest.json) and will use the details there to drive the action.

The contents of the manifest are yet TBD, in its most simple form they can contain scripts that we can put on a temp file, chmod +x the file, run from the process and get a result back to determine the result of the operation. An alternative is to include details on per distro path locations and so on and have dotnet use that to drive the operation.

For example dotnet dev-certs https --trust --check can read the openssl directory location, get the current trusted certificate and check that there is a file with the right name at the openssl certs directory, read the cert and ensure it matches the one in the store.

Onboarding a new distro/version involves the following steps:

Create instructions to install all prerequisites.
Create and share a VHD that can be used for regression testing with the given instructions.
Create a manifest with the details for the distro and version and include it on the dotnet-dev-certs tool as an embedded resource.
Run a suite of manual tests we provide and perform a screen recording so that we can validate all scenarios are working.
Get another person to perform the same steps above to validate that the instructions are correct, complete and that everything works.

For reference, here are some scripts that cover many distros and that can be used as a starting point. The only one completely missing is Alpine, where the install experience just gives you a prompt and you have to run scripts to install everything else. In that case, we likely only need to figure out the work for trusting the cert by openssl since its very likely only used in container environments

CentOS (This likely works for RHEL too)

# Setup Firefox
echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js

echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg

echo "{
    \"policies\": {
        \"Certificates\": {
            \"Install\": [
                \"aspnetcore-localhost-https.crt\"
            ]
        }
    }
}" > policies.json

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt

# Trust Edge/Chrome
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i ./localhost.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i ./localhost.crt

# Trust dotnet-to-dotnet (.pem extension is important here)
sudo cp localhost.crt /etc/pki/tls/certs/aspnetcore-localhost-https.pem
sudo update-ca-trust

# Cleanup
rm localhost.crt

Fedora

# Setup Firefox
echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js

echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg

echo "{
    \"policies\": {
        \"Certificates\": {
            \"Install\": [
                \"aspnetcore-localhost-https.crt\"
            ]
        }
    }
}" > policies.json

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt

# Trust Edge/Chrome
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i ./localhost.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i ./localhost.crt

# Trust dotnet-to-dotnet (.pem extension is important here)
sudo cp localhost.crt /etc/pki/tls/certs/aspnetcore-localhost-https.pem
sudo update-ca-trust

# Cleanup
rm localhost.crt

OpenSUSE (This likely works for SLES too)

# Setup Firefox
echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js

echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg

echo "{
    \"policies\": {
        \"Certificates\": {
            \"Install\": [
                \"aspnetcore-localhost-https.crt\"
            ]
        }
    }
}" > policies.json

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt

# Trust Edge/Chrome
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i ./localhost.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i ./localhost.crt

# Trust dotnet-to-dotnet (.pem extension is important here)
sudo cp localhost.crt /var/lib/ca-certificates/openssl/aspnetcore-localhost-https.pem

# Cleanup
rm localhost.crt

Ubuntu (This likely works for Debian too)

# Setup Firefox
echo "{
    \"policies\": {
        \"Certificates\": {
            \"Install\": [
                \"aspnetcore-localhost-https.crt\"
            ]
        }
    }
}" > policies.json

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv policies.json /usr/lib/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt

# Trust Edge/Chrome
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i ./localhost.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i ./localhost.crt

# Trust dotnet-to-dotnet (.pem extension is important here)
sudo cp localhost.crt /usr/lib/ssl/certs/aspnetcore-https-localhost.pem

# Cleanup
rm localhost.crt

ghost commented 3 years ago

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

jdege commented 3 years ago

I got bit by this, just today.

I'm trying to get OAuth 2.0 and OpenID to work between two local aspnetcore services, using IdentityServer4, and I'm getting certificate chain errors.

https://stackoverflow.com/questions/67910658/how-do-i-trust-dotnets-dev-cert-in-linux

I can't speak to how many others are trying to do what I am, but I at least am having this issue, and it would be nice if the problem was fixed.

mackcoding commented 3 years ago

I can confirm that I am also having this issue.

PhilParisot commented 3 years ago

This worked nicely for me:

https://github.com/dotnet/aspnetcore/issues/7246#issuecomment-744022452

I'm on Ubuntu 20.04.

I was having trouble getting Identity authentication to work on our project, that said the docs really need an update. I spent a ridiculous amount of time not understanding what I was doing wrong, in fact I still can't get Firefox on Ubuntu 20.04 to fully trust the certs (the top-left lock still shows an exclamation mark but the authentication now works, Chrome seems to be fine).

Here are the links to the docs:

https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-5.0&tabs=visual-studio#ubuntu-trust-the-certificate-for-service-to-service-communication

https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-5.0&tabs=visual-studio#trust-https-certificate-on-linux

https://docs.microsoft.com/en-us/dotnet/core/additional-tools/self-signed-certificates-guide#with-dotnet-dev-certs

There should at least be a note on there that says there is known issue with dotnet dev-certs on Linux and redirect to a workaround, it would save a lot of time for a lot of newbies like me.

MarcusXavierr commented 2 years ago

Hello, and do you have any solution for the manjaro?

ariveron commented 2 years ago

Hello, and do you have any solution for the manjaro?

I got it working for Manjaro with the following script. I didn't do it for FireFox because I mainly use Chromium, so you may have to figure that part out.

# Create cert
dotnet dev-certs https

# Export cert to current directory
dotnet dev-certs https -ep localhost.crt --format PEM

# Trust Chromium based browsers
sudo -E dotnet dev-certs https -ep /usr/share/ca-certificates/aspnet/https.crt --format PEM
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/share/ca-certificates/trust-source/anchors/aspnethttps.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/share/ca-certificates/trust-source/anchors/aspnethttps.crt

# Trust wget
sudo cp localhost.crt /usr/share/ca-certificates/trust-source/anchors/aspnetcore-https-localhost.pem
sudo update-ca-trust extract

# Trust dotnet-to-dotnet
sudo cp localhost.crt /etc/ssl/certs/aspnetcore-https-localhost.pem

# Remove cert from current directory
rm localhost.crt

PhilParisot commented 2 years ago

Any updates for this?

meirkr commented 2 years ago

Hi It looks like the following could help to trust the dotnet dev certs: https://blog.wille-zone.de/post/aspnetcore-devcert-for-ubuntu/

javiercn commented 2 years ago

@meirkr we already have this working on a branch. Unfortunately, we do not think we will have time to ensure it has the quality to make it into .NET 7.0 https://github.com/dotnet/aspnetcore/tree/javiercn/dev-certs-linux-trust

ghost commented 2 years ago

Tried running the script above on Redhat 9 with no success for firefox, I can confirm it works with chromium.

ghost commented 2 years ago

add sudo trust anchor localhost.crt to the script for webkit-engine testing with gnome-web

trendzetter commented 2 years ago

This is why you shouldn't use Microsoft shit

DamianEdwards commented 2 years ago

@trendzetter please refrain from posting profanity here.

trendzetter commented 2 years ago

ok, let me rephrase this. this is why you should avoid microsoft products or services at all cost because it always results in monopolistic behavior. First the claim is "cross platform" and then they make you sneakily fail on other platforms by including some hidden nasties. They will never improve.

HummingMind commented 2 years ago

What are you going on about? This issue exists specifically to address the problem and develop a solution. Microsoft should somehow be avoided because this didn't make it into .NET 7 but will be in .NET 8? That is absurd. Did you provide any possible solutions to them instead of conspiracy theories?

DamianEdwards commented 2 years ago

@trendzetter while I appreciate you have your opinions of our products and work, posting comments such as you are on this issue is off topic and not advancing the resolution of this issue in any way.

YohanSciubukgian commented 2 years ago

Could we get some distros available for .NET 7 and/or having it with a « preview » flag so we know that we can face some limitations and wait for .NET 8 to stabilize the whole implementation ? We will be able to use it for testing purpose and give you some feedbacks during .NET 8 dev timeframe.

DamianEdwards commented 2 years ago

@YohanSciubukgian unfortunately it was/is too late in the development cycle to get this into 7.0.0, but it's something on the list for .NET 8 which you could try previews of once available.

trendzetter commented 2 years ago

@HummingMind so I should throw away the dotnet3 LTS app in order to rebuild on yet a new incompatible version with new nasties? I think I'll go for something free of MS next time It's fake cross-platform by design. Best to avoid microsoft services and products at all cost

HummingMind commented 2 years ago

@HummingMind so I should throw away the dotnet3 LTS app in order to rebuild on yet a new incompatible version with new nasties? I think I'll go for something free of MS next time It's fake cross-platform by design. Best to avoid microsoft services and products at all cost

3.0 LTS support ended already anyway. You are also missing out on some insane performance gains by sticking with 3.0. Either way, it is not mandatory to upgrade. You can get HTTPS working on Linux (including Docker Linux Containers) manually.

Also, if I am not mistaken, you should be able to use the future .NET SDK tooling (.NET 8 in this case) to set up the certificates and they will still apply to any old .NET Core runtime, including 3.0 (so your all should benefit too).

If you think other vendors/languages/toolchains are perfect and you never have to upgrade those, I think you are in for a surprise. Free country though! Good luck!

trendzetter commented 2 years ago

The dotnet31 is still advertised as supported despite the short period of promised support by MS for a LTS release. I don't care about performance gains. Reliability is the main concern for many users

trendzetter commented 2 years ago

"hate speech" is what you are gearing up for? This has nothing to do with linux fragmentation, it worked on no linux at all. It has all to do with MS creating an unusable setup for linux and then refusing to provide a fix in the versions it calls "supported" and "cross-platform"

ghost commented 1 year ago

RHEL: dnf install nss-tools

Mozilla uses its own user nss certificate store for each profile. So we can use

    # Certificate import
    dotnet dev-certs https -ep localhost.crt --format PEM
    certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i ./localhost.crt
    certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i ./localhost.crt
    certutil -d sql:$HOME/.mozilla/firefox/{userprofile}/ -A -t "P,," -n localhost -i ./localhost.crt
    certutil -d sql:$HOME/.mozilla/firefox/{userprofile}/ -A -t "C,," -n localhost -i ./localhost.crt

    # Certificate cleanup
    certutil -d sql:$HOME/.pki/nssdb -D -n localhost
    certutil -d sql:$HOME/.mozilla/firefox/{userprofiles}/ -D -n localhost

confirmed working for Edge, Chrome, Firefox on RHEL 8.6. No privilege escalation required. I don't see this not working across all distributions, verification would be appreciated.

I'm not seeing anything in regards to gnome-web supporting an nssdb, a brief repository search for nss leads me to believe support was removed or never fully implemented.

Unless someone knows if Firefox has a way of changing the default nssdb location... Without clearing the existing profile database or escalating privileges, we would need to iterate through each Firefox profile, allow specifying a specific profile, or use the default. New profiles would need to rerundotnet dev-certs --trust.

ghost commented 1 year ago

Setting the SSL_DIR variable to $HOME/.pki/nssdb didn't seem to do anything for curl, I'll look more later.

javiercn commented 1 year ago

There is a branch with a prototype for this here

You can probably clone the branch and run the tool from the repo or follow the same steps the tool uses to trust the cert. In essence you need to export the cert as pem, calculate the hash with c_rehash, and copy it to your openssldir folder.

ghost commented 1 year ago

I'll check it out later tonight

glen-84 commented 1 year ago

I've run the following on Debian bullseye in WSL:

dotnet dev-certs https -ep localhost.crt --format PEM
sudo cp localhost.crt /usr/lib/ssl/certs/aspnetcore-https-localhost.pem

And I still get the following when running dotnet watch:

[14:04:38 WRN] The ASP.NET Core developer certificate is not trusted. For information about trusting the ASP.NET Core developer certificate, see https://aka.ms/aspnet/https-trust-dev-cert.

OpenSSL 1.1.1n 15 Mar 2022

javiercn commented 1 year ago

@glen-84 sudo cp localhost.crt /usr/lib/ssl/certs/aspnetcore-https-localhost.pem is not correct. The certificate in /usr/lib/ssl/certs/ must have a proper name that gets calculated using c_rehash. Otherwise Open SSL just ignores it.

glen-84 commented 1 year ago

@javiercn Oh I see. I thought that the scripts in the OP could be used as-is. I'll try using c_rehash. Thanks.

glen-84 commented 1 year ago

This is driving me insane. What am I doing wrong here?

cd ~
dotnet dev-certs https -ep localhost.crt --format PEM
openssl x509 -noout -fingerprint -sha256 -inform pem -in localhost.crt (use this hash in the file name)
sudo cp localhost.crt /usr/lib/ssl/certs/aspnetcore-https-localhost-AD0940CE8F8294F2CD94D12D736E10A0F935F56289F0AC8AEA1D984EACEAC06F.pem
cd /etc/ssl/certs
sudo c_rehash

I've tried with and without https in the certificate name, and I've tried both a crt and a pem extension. Nothing seems to work.

ghost commented 1 year ago

openSUSE Leap 15.4

dotnet 6.0.406

blazor wasm template

I originally thought this was the correct template. I'll try with the ASP.Net Core hosted template generated in Visual Studio.

Firefox 102.8.0esr

Success

Chromium 110.5481.77 stable

Success

curl 7.79.1

Failed

I can fire it up anytime, let me know if you want me to try a different place for the curl test.

ghost commented 1 year ago

ASP.NET hosted Blazor WASM app generated with Visual Studio - NET 6.0.406 openSUSE 15.4

Unlike Visual studio, I ran the project from the solution directory targeting the Server project.

ghost commented 1 year ago

RHEL 8.6

dotnet 6.0.110

Firefox 102.4.0esr

7.61.1

I might've had a typo in there. I'll look at it later.

DanoThom commented 1 year ago

(Using Windows with Linux Containers via Docker Deskop + WSL2. Testing with 2 simple aspnet core APIs in docker-compose, 1 making an https call to the other via HttpClient.)

I've gone down this rabbit hole for a couple days now. Even if you skip the dotnet dev-certs tools and use openSSL to create a compatible dotnet localhost dev-cert with the special markers, get that .pfx trusted in Windows, and then get the accompanying .crt loaded into and trusted by the container at runtime, API --> API communication is still fundamentally broken. (Keep in mind that both test APIs are using the same certificate files and that I can successfully validate this cert chain in both the Windows host and the container using 'dotnet dev-certs https --check --trust' and 'openssl verify' etc.)

In short, is it true to state that we can get host-to-container SSL trust to work (i.e. chrome website and direct api call), but not for container-to-container trust (i.e. API calling another API)?

crummel commented 1 year ago

@javiercn is this still planned for 8.0? @bartonjs I don't know if you were ever looking at this, were there any crypto concerns with how dev-certs works on Linux?

bartonjs commented 1 year ago

The general problem is that each distro's way of updating system trust is different, particularly with regard to getting it to apply to all tools. That's the reason that we don't enable writing to the LocalMachine\Root store on Linux.

If the dev-certs tool wants to take the distro into account and have distro-specific variance, that seems reasonable to me (off the top of my head). I'd defer here to @blowdart for trying to balance UX with predictability and maintainability.

blowdart commented 1 year ago

Honestly given the fragmentation and no standard way to do it I wouldn't do it at all.

ghost commented 1 year ago

Yeah, I thought that at first and had to retract that statement after thinking better. However, students will hop over to Linux as I once did and want to develop there. The certificate is just to help prevent a scare and bypass the browser security prompt. Little things like that lead up to phycological blocks in creativity. Even I still get spooked when Visual Studio or Rider prompts to add to the firewall, lol. It's a tick.

It doesn't need to go in the root stores, just the users' profiles. Although I don't know about Dotnet-to-Dotnet situations.

ghost commented 1 year ago

https://matrix.to/#/#nss:mozilla.org Just unsure if the support for the NSSdb will remain around.

fmg-lydonchandra commented 1 year ago

For Debian, had to add the following to update-ca-certificates, otherwise dotnet to dotnet did not work with Untrusted root error

# Trust localhost root certificate
sudo cp localhost.crt /usr/local/share/ca-certificates
sudo update-ca-certificates

Full script:

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv policies.json /usr/lib/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt

# Trust Edge/Chrome
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i ./localhost.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i ./localhost.crt

# Trust dotnet-to-dotnet (.pem extension is important here)
sudo cp localhost.crt /usr/lib/ssl/certs/aspnetcore-https-localhost.pem

# Trust localhost root certificate
sudo cp localhost.crt /usr/local/share/ca-certificates
sudo update-ca-certificates

craigwardman commented 1 year ago

Just a heads up, if anyone faces the same issue I had (Linux Mint)

Everything was working fine for quite a while after following the above instructions. One day, however, Edge and Chrome just stopped trusting the cert. Firefox still worked.

After reading this guide: https://learn.microsoft.com/en-gb/aspnet/core/security/enforcing-ssl?view=aspnetcore-7.0&tabs=visual-studio%2Clinux-ubuntu#linux-certificate-not-trusted

I was given the clue that somehow the file permissions on /usr/local/share/ca-certificates/aspnet/https.crt had been reduced to root only. Running sudo chmod 644 /usr/local/share/ca-certificates/aspnet/https.crt fixed the issue for me.

-- Further to the above Chrome/Edge broke again, what I found that works now is to ONLY "P" in NSSDB, i.e. run certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i ./localhost.crt and not this one certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i ./localhost.crt

CarlosDelRosario7 commented 1 year ago

Screenshot-localhost-crt

What worked for me was (on Kali Linux, but it should work on Debian and Ubuntu as well):

sudo apt install mkcert
cd /usr/local/share/ca-certificates
mkcert -install

If you have localhost.crt in the /usr/local/share/ca-certificates directory, then remove it with:

sudo rm -rf localhost.crt

somegenericdev commented 11 months ago

@blowdart it's not like you'd have to cover every meme distro out there. Handling Fedora, Debian and Ubuntu would be enough for 99% of us.

tmds commented 6 months ago

After running into this issue while trying out Aspire on Linux, I put some work into a .NET tool that sets up a development cert on Linux. You can find it here: https://github.com/tmds/linux-dev-certs/.

It should work on Fedora, Debian and Ubuntu.

To use it:

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

amcasey commented 6 months ago

Thanks, @tmds! We're actually planning to revisit this in 9.0. Solving the problem in general remains infeasible, but we should be able to add built-in support for at least Chromium/Firefox/curl on Fedora/Ubuntu/Debian.

amcasey commented 6 months ago

https://github.com/dotnet/aspnetcore/pull/55335 or something like it is likely to be part of this work.

tmds commented 6 months ago

Thanks, @tmds! We're actually planning to revisit this in 9.0. Solving the problem in general remains infeasible, but we should be able to add built-in support for at least Chromium/Firefox/curl on Fedora/Ubuntu/Debian.

@amcasey here is my earlier attempt to make this command work on Linux: https://github.com/dotnet/aspnetcore/pull/33279. It probably has code you can use. I did get some feedback against using a CA certificate: https://twitter.com/tomdeseyn/status/1390590053953462272.

You probably also want .NET itself to trust the development certificate so it can talk to .NET services in an ASP.NET Aspire orchestration.

wgrs commented 6 months ago

After running into this issue while trying out Aspire on Linux, I put some work into a .NET tool that sets up a development cert on Linux. You can find it here: https://github.com/tmds/linux-dev-certs/.

It should work on Fedora, Debian and Ubuntu.

To use it:
dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

Doesnt work for me on Ubuntu 24.04

tmds commented 6 months ago

Doesnt work for me on Ubuntu 24.04

You can create an issue in the repo. Please add some details as to what is not trusted. I verified it with Ubuntu 22.02. For browsers, only the snap-based Firefox browser is expected to work.

wgrs commented 6 months ago

Doesnt work for me on Ubuntu 24.04

You can create an issue in the repo. Please add some details as to what is not trusted. I verified it with Ubuntu 22.02. For browsers, only the snap-based Firefox browser is expected to work.

OK, I was trying it in Edge

dotnet / aspnetcore

[Https] `dotnet dev-certs --trust` support on Linux #32842

openSUSE Leap 15.4

dotnet 6.0.406

blazor wasm template

Firefox 102.8.0esr

Success

Chromium 110.5481.77 stable

Success

curl 7.79.1

Failed

ASP.NET hosted Blazor WASM app generated with Visual Studio - NET 6.0.406 openSUSE 15.4

RHEL 8.6

dotnet 6.0.110

Firefox 102.4.0esr

7.61.1