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

javiercn · 2021-05-19T10:47:19Z

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

The text was updated successfully, but these errors were encountered:

ghost · 2021-05-19T17:48:17Z

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 · 2021-06-10T00:07:05Z

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 · 2021-08-20T15:06:46Z

I can confirm that I am also having this issue.

PhilParisot · 2021-10-28T21:24:14Z

This worked nicely for me:

#7246 (comment)

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 · 2022-01-11T14:34:07Z

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

ariveron · 2022-04-25T00:28:37Z

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 · 2022-05-02T03:13:44Z

Any updates for this?

meirkr · 2022-08-01T12:57:01Z

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 · 2022-08-01T13:17:17Z

@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 · 2022-09-01T16:57:07Z

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

ghost · 2022-09-01T17:12:05Z

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

DamianEdwards · 2022-09-08T15:50:34Z

@trendzetter please refrain from posting profanity here.

trendzetter · 2022-09-09T11:59:45Z

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 · 2022-09-09T14:53:58Z

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 · 2022-09-09T16:34:54Z

@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 · 2022-09-12T19:42:13Z

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 · 2022-09-12T21:27:26Z

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

amcasey · 2024-04-26T21:42:06Z

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 · 2024-04-26T21:42:29Z

#55335 or something like it is likely to be part of this work.

tmds · 2024-04-27T06:34:12Z

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: #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 · 2024-04-30T15:55:46Z

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 · 2024-04-30T15:59:44Z

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 · 2024-04-30T16:02:54Z

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

tmds · 2024-04-30T16:10:28Z

OK, I was trying it in Edge

Feel free to create an issue for it, and I'll look into it when I find some time.

MichaelHochriegl · 2024-05-02T17:25:34Z

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

That's exactly the situation that I'm currently facing. The new preview of Aspire (Preview 6) requires a cert all the way. I can't get the dev cert to be trusted on my Fedora 40 machine. Any help regarding this would be greatly appreciated.

tmds · 2024-05-02T17:28:56Z

@MichaelHochriegl try #32842 (comment).

MichaelHochriegl · 2024-05-02T17:32:03Z

@tmds Doh! I did try it, but didn't restart my machine. After the restart it works flawlessly, sorry for the fuss.
Thanks for this tool 🥰

SimonGeering · 2024-05-29T23:09:58Z

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 thanks it's good to know this hasn't been let fall completely by the wayside.

Prior to something more akin to the windows dev experience arriving in .net 9+ timeframe. In the meantime a single definitive reference document of the manual steps needed that everyone can contribute to or help verify would be helpful.

Personally burnt 5+ hrs on this issue this evening with no success on Ubuntu 24.04 +chrome & edge. There's numerous GitHub issues and scattered docs on ms documentation sites but nothing definitive and nothing works.

Seems particularly important when Linux+.net may be the first experience for many students on tight budget trying to self teach C#. Anything to reduce the cognitive barrier to enter will surely help many!

amcasey · 2024-05-30T00:12:43Z

@SimonGeering Sorry you had to deal with that frustration. We don't have definitive guidance (yet), but hopefully that will be an outcome of this work (i.e. once we know how to do it well, we can recommend solutions for others).

In the meantime, you might want to give the tool linked here a look. I/we/Microsoft can't officially recommend it, but you may nevertheless find that it helps unblock you.

mythz · 2024-06-27T04:47:09Z

For an update on the latest Fedora 40: The only way I was able to get the trinity of loading https://localhost in Chrome and Firefox without cert errors and "dotnet to dotnet" without SSL Exceptions was to use @tmds linux-dev-certs dotnet tool

The current dotnet dev-certs https --trust still prints out a link to https://aka.ms/dev-certs-trust which for Fedora leads down a rabbit hole of stale docs with different approaches that doesn't lead to a working configuration for all scenarios.

Needless to say relying on an unblessed 3rd Party tool as the only way to get a localhost dev good experience wont leave a good impression for new devs trying .NET on Fedora. Ideally dotnet dev-certs https --trust should just work for the major distros: Fedora, Ubuntu, Debian and other .NET supported Linux Distros.

tmds · 2024-06-27T09:54:01Z

still prints out a link to https://aka.ms/dev-certs-trust which for Fedora leads down a rabbit hole of stale docs with different approaches that doesn't lead to a working configuration for all scenarios.

This has been a source of confusion for people using the tool. The upcoming .NET 9 preview 6 should no longer print the message. And, the latest version of the tool prints a message informing the user they can ignore the false warning from ASP.NET Core.

an unblessed 3rd Party tool

Microsoft is working on making the built-in dev-certs work on Linux.

asvishnyakov · 2024-07-02T21:36:24Z

So, nothing of described above worked for me on Ubuntu 22.04.4 with .NET 8 and Google Chrome (yes, Google Chrome, please stop mislabel Chromium as Chrome, looks like they have different ways to store & trust CAs).

My solution was: clean up everything, use linux-dev-certs and then manually import and trust created self-signed CA in chrome://settings/certificates

amcasey · 2024-07-02T21:52:38Z

Draft PR for supporting at least some Linux scenarios: #56582. Please shout if there's some reason this won't work for you.

amcasey · 2024-07-02T21:57:50Z

So, nothing of described above worked for me on Ubuntu 22.04.4 with .NET 8 and Google Chrome

It's possible linux-dev-certs only handles Firefox - @tmds could confirm. If that's the case, I think the fix is just to make the same update to ~/.pki/nssdb.

(yes, Google Chrome, please stop mislabel Chromium as Chrome, looks like they have different ways to store & trust CAs).

Can you please elaborate? In my testing, Chrome, Snap Chrome, Snap Edge, and Chromium all looked in ~/.pki/nssdb for trust, leading me to believe that the family could be treated as a unit.

asvishnyakov · 2024-07-03T02:35:02Z

@amcasey It looks like this code from official documentation (and similar from this trend):

dotnet dev-certs https
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt

just adds server certificate to certificate storage.

If you'll try to import https.crt as CA in Chrome, it will rightfully say that this certificate isn't CA (it's just certificate issued to localhost).

As I remember, on Windows dotnet user-certs https --trust will add base local ASP.NET CA to the Root CA list.

And that's how it worked for me: linux-dev-certs just generate Root CA (asvishnyakov@PC - ASP.NET Core dev CA), then I imported it as CA to Chrome and ASP.NET then generated (without any actions from my side) localhost certificate which is derived from this Root CA.

Here is output of sudo certutil -d ./.pki/nssdb -L:

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

asvishnyakov@PC - ASP.NET Core dev CA                        CT,c,c

and how certificate looks in Chrome:

Compare it to the "default" behavior when only self-signed certificate for localhost is present. This isn't worked for me.

amcasey · 2024-07-03T17:57:51Z

@amcasey It looks like this code from official documentation (and similar from this trend):

dotnet dev-certs https
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt

Do you have a link to those docs? Those steps seem off.

I wouldn't have thought you'd need sudo to export the dev cert. And you almost certainly don't want to run both of those certutil commands - the second will (AFAIK) clobber the first and P is the correct permission for Chrome.

From the linux-dev-certs readme, it sounds like Chrome/Chromium are not yet officially supported, though @tmds would be the expert.

tmds · 2024-07-04T10:54:46Z

From the linux-dev-certs readme, it sounds like Chrome/Chromium are not yet officially supported, though @tmds would be the expert.

Yes, the limitation gets called out in the README. @asvishnyakov, you can open up an issue in the repo, and I'll look into it.

jonashackt · 2024-07-09T10:43:44Z

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

Thanks @tmds - also working on current Manjaro installation using Firefox! Really appreciated!

@ariveron 's solution didn't work for me.

asvishnyakov · 2024-07-11T00:15:56Z

@amcasey https://learn.microsoft.com/en-us/aspnet/core/security/enforcing-ssl?view=aspnetcore-8.0&tabs=visual-studio%2Clinux-ubuntu#ssl-linux
It's link from response of dotnet when you try to run dotnet dev-certs https --trust on Linux:

asvishnyakov@PC:~$ dotnet dev-certs https --trust
Trusting the HTTPS development certificate was requested. Trusting the certificate on Linux distributions automatically is not supported. For instructions on how to manually trust the certificate on your Linux distribution, go to https://aka.ms/dev-certs-trust
A valid HTTPS certificate is already present.

asvishnyakov · 2024-07-11T00:18:04Z

@amcasey You not only need sudo to export certificate, but also need it to run certutil because /usr/local/share subfolders is owned by root. At least on Ubuntu 22.04.5

amcasey · 2024-07-11T00:32:41Z

@asvishnyakov Thanks! Those docs are wrong (now, anyway) - I'll add them to my list.

amcasey · 2024-07-31T22:00:34Z

Fixed by #56582.

Note: it may not work for all clients on all distros, but I'd like to track those exceptions with new issues.

Thanks for your patience, everyone!

Xupack88 · 2024-08-17T06:45:49Z

So, nothing of described above worked for me on Ubuntu 22.04.4 with .NET 8 and Google Chrome (yes, Google Chrome, please stop mislabel Chromium as Chrome, looks like they have different ways to store & trust CAs).

My solution was: clean up everything, use linux-dev-certs and then manually import and trust created self-signed CA in chrome://settings/certificates

On Kubuntu 24.04 using Thorium Browser after running "dotnet linux-dev-certs install" I had to go to "chrome://settings/certificates" and in there to "Authorities" tab as I found out from this SO post: https://superuser.com/questions/1213287/private-key-is-missing-or-invalid-when-importing-a-certificate-in-google-chrom/1276793#1276793 and then import "/etc/ssl/certs/aspnet-dev-username.pem" and check "Trust this certificate for identifying websites" and after that no more errors.

javiercn added area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI feature-devcerts labels May 19, 2021

javiercn mentioned this issue May 19, 2021

don't expose a localhost https endpoint when there is no developer certificate #32361

Closed

mkArtakMSFT added this to the Next sprint planning milestone May 19, 2021

mkArtakMSFT added the enhancement This issue represents an ask for new feature or an enhancement to an existing one label May 19, 2021

tmds mentioned this issue Jun 4, 2021

dotnet-dev-certs: prototype Linux trust support #33279

Closed

adityamandaleeka modified the milestones: Next sprint planning, .NET 7 Planning Sep 10, 2021

PhilParisot mentioned this issue Oct 29, 2021

dotnet dev-certs not working as intended on Linux, docs could use a notice dotnet/AspNetCore.Docs#23686

Closed

DamianEdwards mentioned this issue Jun 1, 2022

[EPIC] Revisiting HTTPS defaults in ASP.NET Core #41990

Closed

10 tasks

DamianEdwards modified the milestones: .NET 7 Planning, .NET 8 Planning Jun 28, 2022

This comment was marked as off-topic.

Sign in to view

amcasey modified the milestones: Backlog, 9.0.0 Apr 26, 2024

amcasey closed this as completed Jul 31, 2024

github-actions bot locked and limited conversation to collaborators Sep 16, 2024

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

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

Comments

javiercn commented May 19, 2021 • edited by DamianEdwards Loading

ghost commented May 19, 2021

jdege commented Jun 10, 2021

mackcoding commented Aug 20, 2021

PhilParisot commented Oct 28, 2021

MarcusXavierr commented Jan 11, 2022

ariveron commented Apr 25, 2022 • edited Loading

PhilParisot commented May 2, 2022

meirkr commented Aug 1, 2022

javiercn commented Aug 1, 2022

ghost commented Sep 1, 2022

ghost commented Sep 1, 2022

This comment was marked as off-topic.

DamianEdwards commented Sep 8, 2022

trendzetter commented Sep 9, 2022 • edited Loading

HummingMind commented Sep 9, 2022

DamianEdwards commented Sep 9, 2022

YohanSciubukgian commented Sep 12, 2022 • edited Loading

DamianEdwards commented Sep 12, 2022

amcasey commented Apr 26, 2024

amcasey commented Apr 26, 2024

tmds commented Apr 27, 2024

wgrs commented Apr 30, 2024 • edited Loading

tmds commented Apr 30, 2024

wgrs commented Apr 30, 2024

tmds commented Apr 30, 2024

MichaelHochriegl commented May 2, 2024

tmds commented May 2, 2024

MichaelHochriegl commented May 2, 2024

SimonGeering commented May 29, 2024

amcasey commented May 30, 2024

mythz commented Jun 27, 2024 • edited Loading

tmds commented Jun 27, 2024

asvishnyakov commented Jul 2, 2024

amcasey commented Jul 2, 2024

amcasey commented Jul 2, 2024

asvishnyakov commented Jul 3, 2024 • edited Loading

amcasey commented Jul 3, 2024

tmds commented Jul 4, 2024

jonashackt commented Jul 9, 2024 • edited Loading

asvishnyakov commented Jul 11, 2024

asvishnyakov commented Jul 11, 2024

amcasey commented Jul 11, 2024 • edited Loading

amcasey commented Jul 31, 2024

Xupack88 commented Aug 17, 2024

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

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

javiercn commented May 19, 2021 •

edited by DamianEdwards

Loading

ariveron commented Apr 25, 2022 •

edited

Loading

trendzetter commented Sep 9, 2022 •

edited

Loading

YohanSciubukgian commented Sep 12, 2022 •

edited

Loading

wgrs commented Apr 30, 2024 •

edited

Loading

mythz commented Jun 27, 2024 •

edited

Loading

asvishnyakov commented Jul 3, 2024 •

edited

Loading

jonashackt commented Jul 9, 2024 •

edited

Loading

amcasey commented Jul 11, 2024 •

edited

Loading