Aspnetcore: Host unreachable in https due to weak Http2 cipher

What OS is the server on? We've seen this on 2012/Win8.

You can opt out of HTTP/2 using these options:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.2#listenoptionsprotocols
E.g.:

{
  "Kestrel": {
    "EndPointDefaults": {
      "Protocols": "Http1"
    }
  }
}

See platform requirements here:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.2#http2-support

Windows 10 - Fast ring insider
Vs2019 preview
netcoreapp3.0.0 preview
(bunch of edge stuff ^^)

was working fine last week. Was hit by an insider bump + latest preview of vs2019 since

also tried to add 2 registry key to disable HTTP2 for Win2016 server.
it had no effect on any browser

Those reg keys are only for IIS/Http.Sys. I wonder if Insiders has a regression. @shirhatti

Is it a way to let developper knows that they are running on a server that may end up like this ?

For example a dotnet tool listing cipher that can be used on the current machine / server with, for example colors to indicate potential weak cipher and so on.
Or a boolean to make the server agressive and failfast if the cipher listed are too weak at startup time.

This would required to know the list of the "acceptable" one and i truly have no idea if such a list exist and if it's possible at all

took me a long time to realize where it was coming from

Can you give the specific windows build number?

We'd only add this kind of tooling if we could no longer say it worked on all rtm win10 builds.

As of the 1803 update, IIS allows you to control Http.Sys on a per binding basis. You no longer need to disable HTTP/2 for the entire server.

That being said, the global reg key should still work. Can you share your Windows build number and I'll look into it

@shirhatti they're using Kestrel.

Whoops 🤦‍♂️. Ignore my previous comment.

also i really don't want to disable Http2 if it can be fixed ;)

@Tratcher
does this helps ?

> systeminfo
OS Version:                10.0.18362 N/A Build 18362
OS Configuration:          Standalone Workstation

> Get-TlsCipherSuite


KeyType               : 0
Certificate           :
MaximumExchangeLength : 0
MinimumExchangeLength : 0
Exchange              :
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 4866
CipherSuite           : 4866
Cipher                : AES
Name                  : TLS_AES_256_GCM_SHA384
Protocols             : {772}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 0
MinimumExchangeLength : 0
Exchange              :
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 4865
CipherSuite           : 4865
Cipher                : AES
Name                  : TLS_AES_128_GCM_SHA256
Protocols             : {772}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 0
MinimumExchangeLength : 0
Exchange              :
HashLength            : 0
Hash                  :
CipherBlockLength     : 0
CipherLength          : 0
BaseCipherSuite       : 0
CipherSuite           : 0
Cipher                :
Name                  : TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Protocols             : {}

KeyType               : 0
Certificate           : ECDSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 49195
CipherSuite           : 49195
Cipher                : AES
Name                  : TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 49200
CipherSuite           : 49200
Cipher                : AES
Name                  : TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 49199
CipherSuite           : 49199
Cipher                : AES
Name                  : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 1024
MinimumExchangeLength : 1024
Exchange              : DH
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 159
CipherSuite           : 159
Cipher                : AES
Name                  : TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 1024
MinimumExchangeLength : 1024
Exchange              : DH
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 158
CipherSuite           : 158
Cipher                : AES
Name                  : TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 0
MinimumExchangeLength : 0
Exchange              :
HashLength            : 0
Hash                  :
CipherBlockLength     : 0
CipherLength          : 0
BaseCipherSuite       : 0
CipherSuite           : 0
Cipher                :
Name                  : TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Protocols             : {}

KeyType               : 0
Certificate           : ECDSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 256
Hash                  : SHA256
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 49187
CipherSuite           : 49187
Cipher                : AES
Name                  : TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 384
Hash                  : SHA384
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 49192
CipherSuite           : 49192
Cipher                : AES
Name                  : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 256
Hash                  : SHA256
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 49191
CipherSuite           : 49191
Cipher                : AES
Name                  : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : ECDSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 160
Hash                  : SHA1
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 49162
CipherSuite           : 49162
Cipher                : AES
Name                  : TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Protocols             : {769, 770, 771, 65279...}

KeyType               : 0
Certificate           : ECDSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 160
Hash                  : SHA1
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 49161
CipherSuite           : 49161
Cipher                : AES
Name                  : TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
Protocols             : {769, 770, 771, 65279...}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 160
Hash                  : SHA1
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 49172
CipherSuite           : 49172
Cipher                : AES
Name                  : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Protocols             : {769, 770, 771, 65279...}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 65536
MinimumExchangeLength : 0
Exchange              : ECDH
HashLength            : 160
Hash                  : SHA1
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 49171
CipherSuite           : 49171
Cipher                : AES
Name                  : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
Protocols             : {769, 770, 771, 65279...}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 16384
MinimumExchangeLength : 512
Exchange              : RSA
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 157
CipherSuite           : 157
Cipher                : AES
Name                  : TLS_RSA_WITH_AES_256_GCM_SHA384
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 16384
MinimumExchangeLength : 512
Exchange              : RSA
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 156
CipherSuite           : 156
Cipher                : AES
Name                  : TLS_RSA_WITH_AES_128_GCM_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 16384
MinimumExchangeLength : 512
Exchange              : RSA
HashLength            : 256
Hash                  : SHA256
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 61
CipherSuite           : 61
Cipher                : AES
Name                  : TLS_RSA_WITH_AES_256_CBC_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 16384
MinimumExchangeLength : 512
Exchange              : RSA
HashLength            : 256
Hash                  : SHA256
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 60
CipherSuite           : 60
Cipher                : AES
Name                  : TLS_RSA_WITH_AES_128_CBC_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 16384
MinimumExchangeLength : 512
Exchange              : RSA
HashLength            : 160
Hash                  : SHA1
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 53
CipherSuite           : 53
Cipher                : AES
Name                  : TLS_RSA_WITH_AES_256_CBC_SHA
Protocols             : {769, 770, 771, 65279...}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 16384
MinimumExchangeLength : 512
Exchange              : RSA
HashLength            : 160
Hash                  : SHA1
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 47
CipherSuite           : 47
Cipher                : AES
Name                  : TLS_RSA_WITH_AES_128_CBC_SHA
Protocols             : {769, 770, 771, 65279...}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 16384
MinimumExchangeLength : 512
Exchange              : RSA
HashLength            : 160
Hash                  : SHA1
CipherBlockLength     : 8
CipherLength          : 168
BaseCipherSuite       : 10
CipherSuite           : 10
Cipher                : 3DES
Name                  : TLS_RSA_WITH_3DES_EDE_CBC_SHA
Protocols             : {769, 770, 771, 768...}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 16384
MinimumExchangeLength : 512
Exchange              : RSA
HashLength            : 256
Hash                  : SHA256
CipherBlockLength     : 1
CipherLength          : 0
BaseCipherSuite       : 59
CipherSuite           : 59
Cipher                :
Name                  : TLS_RSA_WITH_NULL_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           : RSA
MaximumExchangeLength : 16384
MinimumExchangeLength : 512
Exchange              : RSA
HashLength            : 160
Hash                  : SHA1
CipherBlockLength     : 1
CipherLength          : 0
BaseCipherSuite       : 2
CipherSuite           : 2
Cipher                :
Name                  : TLS_RSA_WITH_NULL_SHA
Protocols             : {769, 770, 771, 768...}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 0
MinimumExchangeLength : 0
Exchange              :
HashLength            : 0
Hash                  :
CipherBlockLength     : 0
CipherLength          : 0
BaseCipherSuite       : 0
CipherSuite           : 0
Cipher                :
Name                  : TLS_PSK_WITH_AES_256_GCM_SHA384
Protocols             : {}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 256
MinimumExchangeLength : 0
Exchange              : PSK
HashLength            : 0
Hash                  :
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 168
CipherSuite           : 168
Cipher                : AES
Name                  : TLS_PSK_WITH_AES_128_GCM_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 256
MinimumExchangeLength : 0
Exchange              : PSK
HashLength            : 384
Hash                  : SHA384
CipherBlockLength     : 16
CipherLength          : 256
BaseCipherSuite       : 175
CipherSuite           : 175
Cipher                : AES
Name                  : TLS_PSK_WITH_AES_256_CBC_SHA384
Protocols             : {771, 65277}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 256
MinimumExchangeLength : 0
Exchange              : PSK
HashLength            : 256
Hash                  : SHA256
CipherBlockLength     : 16
CipherLength          : 128
BaseCipherSuite       : 174
CipherSuite           : 174
Cipher                : AES
Name                  : TLS_PSK_WITH_AES_128_CBC_SHA256
Protocols             : {771, 65277}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 256
MinimumExchangeLength : 0
Exchange              : PSK
HashLength            : 384
Hash                  : SHA384
CipherBlockLength     : 1
CipherLength          : 0
BaseCipherSuite       : 177
CipherSuite           : 177
Cipher                :
Name                  : TLS_PSK_WITH_NULL_SHA384
Protocols             : {771, 65277}

KeyType               : 0
Certificate           :
MaximumExchangeLength : 256
MinimumExchangeLength : 0
Exchange              : PSK
HashLength            : 256
Hash                  : SHA256
CipherBlockLength     : 1
CipherLength          : 0
BaseCipherSuite       : 176
CipherSuite           : 176
Cipher                :
Name                  : TLS_PSK_WITH_NULL_SHA256
Protocols             : {771, 65277}

@tebeco Can you provide us with a wireshark trace so that we can see exactly what is being negotiated? Thanks!

cc @anurse

What filter would i use to extract what you are looking for, pretty sure i can leak data i don't want too
Also i have a doubt i actually see something :

• With chrome i have no logs out of Kestrel
• With Firefox i got this :

info: Microsoft.AspNetCore.Server.Kestrel[20]
      Connection id "xxxxxxxxxxxxxxxxxxx" request processing ended abnormally.
System.IO.IOException: The decryption operation failed, see inner exception. ---> System.ComponentModel.Win32Exception: An unknown error occurred while processing the certificate.
   --- End of inner exception stack trace ---
   at System.Net.Security.SslStreamInternal.ReadAsyncInternal[TReadAdapter](TReadAdapter adapter, Memory`1 buffer)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.AdaptedPipeline.ReadInputAsync(Stream stream)
   at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
   at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
   at System.IO.Pipelines.Pipe.GetReadAsyncResult()
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext](IHttpApplication`1 application)

i guess that for now i'll keep on using Firefox to do a capture but i either choose bad options when installing wireshark (lots of question about loopback/wifi/admin etc ...) and i might have opt_out from too many options

also i tried to use this filter : tcp.port == 5043 (which is supposed to be the Kestrel port)
and i see nothing

also i did not yes disabled H2, soooo is that normal :

(the double rounded value is a bonus)

@shirhatti

would really like to do a Wireshark capture
I'm using a laptop (so Wifi) and using localhost for kestrel
on a laptop that has now ~6-8 Network adapter

what's the best way to have a clean and nice capture ?

also what capturing filter should i use to filter what you need ?

Similar issue: https://github.com/aspnet/AspNetCore/issues/8409

I can reproduce this on 18356.21 and #8409 also reports it on 18362.1.

Note it works in IE and Edge so this is a conflict of what ciphers Windows supports vs what Chrome supports.

@Tratcher
Well Chrome and Firefox
that's a bit nasty

It's likely not that the [dev] cert itself is insecure, but that it's only compatible with certain cipher suits. i.e. I don't think it works with EC cyphers. The negotiation falls back to cert compatible ciphers and apparently doesn't find one that meets HTTP/2 requirements.

@Tratcher's comment from the other thread

What can i do to help ?

@tebeco I think we have enough to go on now, thanks.

Bringing into preview5.

The work around, if you can, is to use Vs.net and IIS Express and debug that way because the IIS Express dev cert works correctly even on windows insider releases. Solves the problem for now for those hitting this.

Another datapoint: We tested using IIS Express's cert in Kestrel and it also worked, we'll see what needs to change with the AspNetCore dev cert.

@Tratcher Do you have steps to do so? Would be a sweet workaround for now. Glad it worked!

@anurse can you paste in your code sample?

Yep. We intend to fix our dev cert for 3.0, but as a temporary workaround you can use the IIS Express development certificate directly from Kestrel.

This only works on Windows (but so far the problem has only been reported there), and requires that you have IIS Express installed and configured (installing VS is sufficient for this). You do not actually have to use IIS Express to host your site, we're just borrowing it's development certificate :).

First you need to find your IIS Express cert in the user certificate store and get the thumbprint. The followng PowerShell script will do the trick:

dir Cert:\CurrentUser\Root\ | Where { $_.FriendlyName -like "IIS Express*" } | Select Thumbprint

Once you've got the thumbprint, you can write a small bit of code in Program.cs to grab that certificate out of the store and use it for Kestrel.

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();

                // Add this section below
                webBuilder.ConfigureKestrel(options =>
                {
                    options.ConfigureHttpsDefaults(ssl =>
                    {
                        // Open the Current User's Trusted Root Certificate store
                        var store = new X509Store(StoreName.Root, StoreLocation.CurrentUser);
                        store.Open(OpenFlags.ReadOnly);

                        // Find the IIS Express Certificate
                        var cert = store.Certificates.Find(X509FindType.FindByThumbprint, "<<put the hex thumbprint value in here>>", validOnly: false);
                        ssl.ServerCertificate = cert.Cast<X509Certificate2>().First();
                    });
                });
            });
}

@anurse Awesome! Thanks!

We need to update our dev cert. @javiercn is that something you can look at? The IIS Express Dev Cert in Win 10 18356 works fine, but ours doesn't. All we need to do is make sure we match the same requirements.

This is high priority for preview 5 since the dev certificate is completely broken on Windows 10 19H1.

cc @mkArtakMSFT

@anurse Having read through the issue, but should be doable. Will have to let @blowdart know but if we are just making the key for a more modern key that should be fine. (Again, haven't read the issue, but I imagine that's it).

That's my understanding. As I said, we know the IIS Express certificate is doing it right, we just need to figure out what's different and apply that change to our certificate too :).

@shirhatti do you know anyone who would know specifically what change was made in the IIS certificate? Might help save some diving into cert details if we just knew the changes that were made :)

I've taken a look at this by creating a windows 10 machine, updating it to the lastest insider build and installing vs (so that IIS installs the cert).

I haven't been able to see anything on the cert. Can anyone export a "working cert" and share it with me so that I can take a look at it? I only need the public part.

Certs.zip

Here's both so you can compare. Also note that the ASP.NET Core cert is in the personal store of the current user and the IIS Express cert is in the Personal store of the local machine if it matters.

@anurse I've taken a look at this. The certificates are primarily identical (based on the certs provided by @JohnGalt1717) but for a couple of things:

• Basic constraints: We put them in, IIS does not. They shouldn't matter.
• Key usage: We only add key encipherment while IIS does add Digital Signature and Data encipherment.

My working theory is that the TLS suite being resolved is different between the two. @Tratcher can you get the negotiated suite for both certs? For some reason, with our cert it is likely that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is not being picked on. (That reads Eliptic Curve Diffie-Helman Ephemeral for key exchange, RSA for authentication, AES128 Galois Counter Mode for encryption).

Based on this, the likely solution is to simply add Digital Signature to the key usage. That said, I think it warrants looking at the default set of cipher suites used by Kestrel and IIS and compare them, as my guess is that Kestrel is downgrading to something unacceptable, so changing our cert will only put a band-aid on the problem and not fix it properly.

@anurse The powershell snippet below will create a "aspnetcore compatible" https cert with the addition of Digital Signature. I've been trying to repro this on the Win 10 insider builds and I haven't been able to. Can you get someone on the team to try it out?

More importantly I think we should review the cipher suites offered by IIS and Kestrel. I'm not sure adding the change above is correct, and I would like @blowdart to chime in

function TryCreateAspNetCoreCertUsingPowershell () {
    $ekuOidCollection = [System.Security.Cryptography.OidCollection]::new();
    $ekuOidCollection.Add([System.Security.Cryptography.Oid]::new("1.3.6.1.5.5.7.3.1","Server Authentication"));
    $sanBuilder = [System.Security.Cryptography.X509Certificates.SubjectAlternativeNameBuilder]::new();
    $sanBuilder.AddDnsName("localhost");

    $certificateExtensions = @(
        # Subject Alternative Name
        $sanBuilder.Build($true),        
        # ASP.NET Core OID
        [System.Security.Cryptography.X509Certificates.X509Extension]::new(
            "1.3.6.1.4.1.311.84.1.1",
            [System.Text.Encoding]::ASCII.GetBytes("ASP.NET Core HTTPS development certificate"),
            $false),
        # KeyUsage
        [System.Security.Cryptography.X509Certificates.X509KeyUsageExtension]::new(
            [System.Security.Cryptography.X509Certificates.X509KeyUsageFlags]::KeyEncipherment -bor [System.Security.Cryptography.X509Certificates.X509KeyUsageFlags]::DigitalSignature,
            $true),
        # Enhanced key usage
        [System.Security.Cryptography.X509Certificates.X509EnhancedKeyUsageExtension]::new(
            $ekuOidCollection,
            $true),
        # Basic constraints
        [System.Security.Cryptography.X509Certificates.X509BasicConstraintsExtension]::new($false,$false,0,$true))
    $parameters = @{
        Subject = "localhost";
        KeyAlgorithm = "RSA";
        KeyLength = 2048;
        CertStoreLocation = "Cert:\CurrentUser\My";
        KeyExportPolicy = "Exportable";
        NotBefore = Get-Date;
        NotAfter = (Get-Date).AddYears(1);
        HashAlgorithm = "SHA256";
        Extension = $certificateExtensions;
        SuppressOid = @("2.5.29.14");
        FriendlyName = "ASP.NET Core HTTPS development certificate"
    }
    New-SelfSignedCertificate @parameters
}

If you used the insider build from yesterday that is 20H1 not 19H1. You'll need to do the release preview ring or slow ring to get the version with the issue. (Maybe this is an issue with the now final 19H1?)

I'm ok with adding that EKU.

I repro'd the issue just now, then installed @javiercn 's updated cert and switched to it and the issue no longer repros with the updated cert.

https://github.com/aspnet/AspNetCore/pull/9293/files PR is out to update the KU.

PR merged. Close it if you feel there's nothing else to address here

i just updated to 20H1 yesterday
i'm not sure what preview 3.0.0-previewX will contains the merge
can you enlighten me on it ? preview4 or 5 ?
(i'm can test a nightly but not willing to use it after the quick test)

This will be part of preview5.

If you run

dotnet dev-certs http --clean

The powershell script above and then

dotnet dev-certs http --trust

It should unblock you.

Thanks everyone. This is now fixed and I'll follow up regarding including this in the Known issues for Preview5 release.

There's a typo in https://github.com/aspnet/AspNetCore/issues/8952#issuecomment-482499042, but when corrected, this worked:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Just installed preview 6 and this still happend.
Chrome reports ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY.

I haven't installed any preview before, only SDK 2.0 and up.

SDK/Runtime version: 3.0.100-preview6-012264.

Might be related to https://github.com/aspnet/AspNetCore/issues/11283 for me.

@nphmuller

Did you try running the following commands with a preview6 dotnet environment?

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Its likely that you have an old cert. We added logic to upgrade the certificate, but I'm not sure if it made it into preview6 or will be available on preview7.

@javiercn
I tried, as a workaround, but --clean fails. I've created https://github.com/aspnet/AspNetCore/issues/11283 for this issue.

@nphmuller What OS are you using?

You can open the cert manager and clean the certs yourself (I get this is not ideal)
On windows (Win+R) -> mmc -> enter -> (Ctrl+M (add snap-in) -> Certificates -> My user account -> Certificates -> Personal -> Certificates -> Find the ones with 'localhost' -> Remove the ones that have ASP.NET Core HTTPS ....
Repeat with the certificates on Trusted Root Certification Authorities
Re-run dotnet dev-certs https --trust

@javiercn
That work. Thanks!
I'm on Win 10 1903 (18362.175) (Also in the dotnet --info output, I've written in my initial comment)

My guess would be, as you wrote, that the upgrade logic hadn't made it to preview 6, but will be in preview 7.

@javiercn @nphmuller I had the same problem, tried removing certificates manually and re-creating them using dotnet dev-certs https --trust. That worked, but now I get a ERR_CERT_AUTHORITY_INVALID error. It looks like Kestrel is still using the old certificate. Any ideas?

Did you close and reopen your browser windows? Browsers cache certs in memory, so you need to close and open a new browser for the changes to show up.

Yep, I did. I also restarted my computer just now. Doesn't seem to work (tried in Chrome, Firefox, Edge). Is there any place where the certificate might be cached? It looks like the certificate is indeed the previous one.

Did you use the 3.0 SDK to generate the certificate?

Yes, I think so. dotnet --info output looks similar to @nphmuller 's:

dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview6-012264
 Commit:    be3f0c1a03

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18362
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100-preview6-012264\

Host (useful for support):
  Version: 3.0.0-preview6-27804-01
  Commit:  fdf81c6faf

.NET Core SDKs installed:
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.500 [C:\Program Files\dotnet\sdk]
  2.1.502 [C:\Program Files\dotnet\sdk]
  2.1.503 [C:\Program Files\dotnet\sdk]
  2.1.504 [C:\Program Files\dotnet\sdk]
  2.1.505 [C:\Program Files\dotnet\sdk]
  2.1.600-preview-009426 [C:\Program Files\dotnet\sdk]
  2.1.600-preview-009472 [C:\Program Files\dotnet\sdk]
  2.1.600-preview-009497 [C:\Program Files\dotnet\sdk]
  2.1.600 [C:\Program Files\dotnet\sdk]
  2.1.601 [C:\Program Files\dotnet\sdk]
  2.1.602 [C:\Program Files\dotnet\sdk]
  2.1.604 [C:\Program Files\dotnet\sdk]
  2.1.700 [C:\Program Files\dotnet\sdk]
  2.2.200-preview-009648 [C:\Program Files\dotnet\sdk]
  2.2.200-preview-009748 [C:\Program Files\dotnet\sdk]
  2.2.200-preview-009804 [C:\Program Files\dotnet\sdk]
  2.2.200 [C:\Program Files\dotnet\sdk]
  2.2.201 [C:\Program Files\dotnet\sdk]
  2.2.202 [C:\Program Files\dotnet\sdk]
  2.2.204 [C:\Program Files\dotnet\sdk]
  2.2.300 [C:\Program Files\dotnet\sdk]
  3.0.100-preview6-012264 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0-preview6.19307.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0-preview6-27804-01 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0-preview6-27804-01 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

On windows too?

dotnet --info just list the sdks
you could have been affected by a global.json in that folder or any parent folder
that would result in regenerating the same old certificate

try a clean up
check dotnet --version
then use the --trust command

@javiercn What do you mean? I am on Windows. 🙂

@tebeco dotnet --version prints 3.0.100-preview6-012264 as well.

the issue is that you need to be sure of that when you actually ran that command at that moment

I can't really follow along. What am I supposed to do? 😕

do a full cleanup
no idea if reboot required
then check the dotnet version before re-running the --trust one

That's what I already did (a few times) 🙂 -- still no success.

I have a freshly installed VS2019 Preview 16.2 Preview 2 and this is the first ASP.NET core with Kestrel project that I run and I'm hitting the same issue. I've tried the clean/trust commands to refresh the certificate with no change.

dotnet --version
3.0.100-preview-010184

This is an empty project with .ConfigureKestrel() added without any changes

@karaziox the 3.0.100-preview-010184 SDK is from 3.0.0-preview2, where this issue wasn't fixed until preview6. Go to https://dotnet.microsoft.com/download/dotnet-core/3.0 and install SDK 3.0.100-preview6-012264.

@javiercn What do you mean? I am on Windows. 🙂

@tebeco dotnet --version prints 3.0.100-preview6-012264 as well.

@Tratcher the problem still occurs in preview6.

I believe the fix is in preview7, not preview6. @jkotalik can you confirm?

Still an issue for me with dotnet 3.0.100-preview6-012264 and VS 16.2.0 Preview 3.0

IIS works fine with default ASP.Net Core Application, Kestrel fails with ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

@simonmurdock can you try manually regenerating the certificate on the command line with dotnet dev-certs https --clean and dotnet dev-certs https --trust. There were a few issues resolved regarding user experience that will be fixed in preview7, but the certificate should work if regenerated in preview6.

Hi. Same issue for me 3.0.100-preview6-012264 (OS Win 8.1), have installed VS2019 16.1.1. Verified out with dotnet new blazorhosted. I tried cleaning the certs (closing chrome 75.0.3770.100) with the dotnet tool and trusting again but no help.

@vmandic HTTP/2 isn't supported on Win8.1, you'll need to turn it off.
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.2#http2-support

@Tratcher we should probably disable HTTP2 by default if running on Win7 or Win8

@jkotalik open a new issue for triage please. In theory it can work on Win8.1, there's just an issue with the cypher ordering and getting a cert that supports some of the alternate cyphers.

Since the issue still wasn't resolved when I installed Preview8 yesterday, I tried to run both dotnet dev-certs https --clean and dotnet dev-certs https --trust again, without success.

I found that Kestrel was still using an old, outdated certificate, but I wasn't able to locate the said certificate in the Windows certificate manager. Turns out that the certificates are cached here: C:\Users\<user>\AppData\Roaming\ASP.NET\Https. There were three *.pfx files, one of which was obviously still used by Kestrel.

It took me literally hours to find this. I was already expecting that certificates are cached, but I was unable to find it somewhere in the documentation. This really needs to be documented, please.

I imagine that's because you are using docker containers. That's the location where docker exports the certificate to import it into the container.

@anurse we could add this to the docs I think. I'm not sure the implications cleaning this folder have for the docker folks, but we can ask them.

What I don't want is to add this to the tool, as its a docker tooling implementation detail and has nothing to do with the tool.

That said, I don't think we need to change the runtime here so long as we provide details on what to do if you run into this situation in the docs. I've filed https://github.com/aspnet/AspNetCore.Docs/issues/13927 to track it.

Thanks for elaborating.

Adding this to the documentation will help folks save some time. Thanks a lot!