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

[javiercn]

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]

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]

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]

I can confirm that I am also having this issue.

[PhilParisot]

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]

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

[ariveron]

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]

Any updates for this?

[meirkr]

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]

@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]

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

[ghost]

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

[trendzetter]

This is why you shouldn't use Microsoft shit

[DamianEdwards]

@trendzetter please refrain from posting profanity here.

[trendzetter]

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]

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]

@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]

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]

@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]

@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]

@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]

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]

"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]

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]

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

[javiercn]

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]

I'll check it out later tonight

[glen-84]

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]

@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]

@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]

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.