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

ghost · 2023-02-26T14:37:31Z

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 · 2023-03-02T11:36:10Z

(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 · 2023-03-02T15:42:54Z

@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 · 2023-03-02T20:21:10Z

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 · 2023-03-02T20:29:04Z

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

ghost · 2023-03-02T21:50:28Z

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 · 2023-03-02T21:59:00Z

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

fmg-lydonchandra · 2023-03-11T12:46:38Z

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 · 2023-06-28T15:08:18Z

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 · 2023-09-17T23:58:18Z

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 · 2023-12-02T18:57:41Z

@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 · 2024-04-22T14:44:04Z

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 · 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 🥰

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

ghost mentioned this issue Mar 5, 2023

[Proposal] Leverage Sqlite for Desktop https developer-certificates. #47042

Closed

baronfel mentioned this issue Jul 5, 2023

Containers: Protocol correctness and quirk handling for Basic and Bearer authentication for registries dotnet/sdk#33753

Merged

amcasey modified the milestones: .NET 8 Planning, Backlog Feb 14, 2024

amcasey self-assigned this Apr 26, 2024

amcasey modified the milestones: Backlog, 9.0.0 Apr 26, 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

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

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

HummingMind commented Sep 9, 2022

DamianEdwards commented Sep 9, 2022

YohanSciubukgian commented Sep 12, 2022 • edited

DamianEdwards commented Sep 12, 2022

ghost commented Feb 26, 2023

RHEL 8.6

dotnet 6.0.110

Firefox 102.4.0esr

7.61.1

DanoThom commented Mar 2, 2023

crummel commented Mar 2, 2023

bartonjs commented Mar 2, 2023

blowdart commented Mar 2, 2023

ghost commented Mar 2, 2023 • edited by ghost

ghost commented Mar 2, 2023 • edited by ghost

fmg-lydonchandra commented Mar 11, 2023 • edited

craigwardman commented Jun 28, 2023 • edited

CarlosDelRosario7 commented Sep 17, 2023

somegenericdev commented Dec 2, 2023

tmds commented Apr 22, 2024 • edited

amcasey commented Apr 26, 2024

amcasey commented Apr 26, 2024

tmds commented Apr 27, 2024

wgrs commented Apr 30, 2024 • edited

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

[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

ariveron commented Apr 25, 2022 •

edited

trendzetter commented Sep 9, 2022 •

edited

YohanSciubukgian commented Sep 12, 2022 •

edited

ghost commented Mar 2, 2023 •

edited by ghost

ghost commented Mar 2, 2023 •

edited by ghost

fmg-lydonchandra commented Mar 11, 2023 •

edited

craigwardman commented Jun 28, 2023 •

edited

tmds commented Apr 22, 2024 •

edited

wgrs commented Apr 30, 2024 •

edited