ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY when clean webapi template

[hristijankiko]

Describe the bug

A clear and concise description of what the bug is.

When https is used chrome and other browsers error out with ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY when the api is accessed.

To Reproduce

Steps to reproduce the behavior:

1. Create a new webapi application and run it
2. Visit its url in a browser (with https redirection enabled)
3. See error

Expected behavior

A clear and concise description of what you expected to happen.
The api should be available through https as is through http.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Generating new https certificates did not help(dotnet dev-certs https --clean and dotnet dev-certs https --trust).

.NET Core SDK (reflecting any global.json):
Version: 3.0.100
Commit: 04339c3a26

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\

Host (useful for support):
Version: 3.0.0
Commit: 7d57652f33

.NET Core SDKs installed:
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.302 [C:\Program Files\dotnet\sdk]
2.1.504 [C:\Program Files\dotnet\sdk]
2.1.600-preview-009472 [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.700-preview-009597 [C:\Program Files\dotnet\sdk]
2.1.700-preview-009601 [C:\Program Files\dotnet\sdk]
2.1.700-preview-009618 [C:\Program Files\dotnet\sdk]
2.1.700 [C:\Program Files\dotnet\sdk]
2.1.800-preview-009677 [C:\Program Files\dotnet\sdk]
2.1.801 [C:\Program Files\dotnet\sdk]
2.1.802 [C:\Program Files\dotnet\sdk]
3.0.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [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.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [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.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [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.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0-rc1-19456-20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

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

[andrewaggb]

Well this isn't an official solution or anything, but what worked for me when upgrading an existing .net core 2.2 project to .net core 3 was

make a new .net core 3 mvc project. Right click the project, choose manage user secrets, copy the user secrets, paste those user secrets over top of my existing user secrets.
{
"Kestrel:Certificates:Development:Password": "replace with value from new working project"
}

[hristijankiko]

This is not an issue with an existing project, it happens with a clean template of a newly create webapi project, and I assume it should be able to work out of the box without any re-configuration

[poke]

I have the same problem on 3.0, with a blank web project and a freshly created certificate, on Windows 8.1. /cc @Tratcher

If it helps, these are the details of the generated certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            d2:17:2f:03:4d:cc:cd:f4
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = localhost
        Validity
            Not Before: Sep 24 09:49:19 2019 GMT
            Not After : Sep 23 09:49:19 2020 GMT
        Subject: CN = localhost
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus: […]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: critical
                TLS Web Server Authentication
            X509v3 Subject Alternative Name: critical
                DNS:localhost
            1.3.6.1.4.1.311.84.1.1:
                .
    Signature Algorithm: sha256WithRSAEncryption
         […]

For SEO purposes: On Firefox, the error is SEC_ERROR_INADEQUATE_KEY_USAGE .

[dasMulli]

@poke and i did some investigations. Looks like his machine chooses to use ECDHE-RSA-AES256-SHA384 as cipher for the TLS session which is not allowed for http2.
On my windows 10 1903 without any registry config the chosen cipher ens up being ECDHE-RSA-AES256-GCM-SHA384 which works.

[javiercn]

I believe you need to update the dev-cert on the machine. Run dotnet dev-certs https --trust and re-run the application (closing and reopening all windows of the browser after running the command).

If that doesn't work, let us know and try dotnet dev-certs https --clean followed by dotnet dev-certs https --trust.

You should use the 3.0 version of the tool just to be sure (I think we patched something like this in 2.2 or 2.1, but I'm not sure).

/cc @anurse

[poke]

@javiercn

If that doesn't work, let us know and try dotnet dev-certs https --clean followed by dotnet dev-certs https --trust.

That’s exactly what I did in the first place. So yeah, that doesn’t help :/ Tell me if you need any additional information.

[javiercn]

@poke are you using the 3.0 dotnet dev-certs tool?

@Tratcher ideas?

Tell me if you need any additional information.

Can you export the certificate from your local machine and share it with us? Just to make sure its the correct cert.

[poke]

@javiercn Yeah, the 3.0 SDK release version from yesterday.

Can you export the certificate from your local machine and share it with us?

Sure, here you go.

[Tratcher]

@poke On Win8.1 you should disable HTTP/2 or manually adjust your ciphers. The default cipher list doesn't work for Http/2 as you've noticed. We weren't immediately concerned about Win8.1 because you're one of the only people still using it 😁 (< 5% usage). Win7 clients aren't affected because they don't support ALPN.

@hristijankiko's issue is something else.

[poke]

@Tratcher Heh, I’m not using it by total choice (upgrading the work machine is a major PITA; it is planned but I need a lot of time for that). Can I adjust the ciphers of Windows without modifying the application? I would like to avoid having to add code to the application just to work around my machine-specific issue. I guess I could also adjust my user secrets to override the Kestrel settings there (disabling HTTP/2) 🤔

[Tratcher]

Windows ciphers can only be adjusted in the registry.

Disabling HTTP2 in config is easier. Here's an example that disables HTTP/1.1.
https://github.com/aspnet/AspNetCore/blob/0a26524af0121e9db4ad1f3a6f98e33c3b52cdbd/src/ProjectTemplates/Web.ProjectTemplates/content/GrpcService-CSharp/appsettings.json#L9-L13

[poke]

Hmm, restricting it to HTTP/1 only resolved the problem in Chrome. Firefox still raises this error:

An error occurred during a connection to localhost:5001. Certificate key usage inadequate for attempted operation. Error code: SEC_ERROR_INADEQUATE_KEY_USAGE

[Tratcher]

@javiercn is this related to firefox using its own cert store, trust doesn't work for them?
https://bugzilla.mozilla.org/show_bug.cgi?id=1570222

[javiercn]

@Tratcher very likely. I’ve never been able to make a self-signed cert work on Firefox

[Tratcher]

That's a major gap in our doc coverage then.

[javiercn]

@Tratcher on a second look I don’t think that’s the issue. I don’t believe we have a critical security extension that is not standard

[poke]

Firefox has its own certificate store, yes, but if you visit a site with a self-signed certificate, you would usually get some error like SEC_ERROR_UNKNOWN_ISSUER or ERROR_SELF_SIGNED_CERT, where you can always choose to continue to the “untrusted” website.

I’m back home now and have a Windows 10 machine to test this, and I do get the same error on Firefox here. Interestingly, I did not refresh the dev certificate, so I am still using one that was generated somewhen in July (probably some 2.2.x). When I create a blank Razor app (dotnet new razor) and run that, then I get the same error SEC_ERROR_INADEQUATE_KEY_USAGE as before.

However, when I create the same thing on 2.2.401 (using a global.json), then I can browse that application just fine. So this cannot be a problem with the certificate and also not with Firefox (directly) since on 2.2 the combination works. So it must be Kestrel that is negotiating something differently.

Let me know what I should do to give you more debugging information.

[analogrelay]

Interestingly, I did not refresh the dev certificate, so I am still using one that was generated somewhen in July (probably some 2.2.x). When I create a blank Razor app (dotnet new razor) and run that, then I get the same error SEC_ERROR_INADEQUATE_KEY_USAGE as before.

If you didn't refresh the cert after 2.2 then it's probably the known issue that requires cert regeneration. The cert generated in 2.2 was broken by a Windows update, not by 3.0. If you are running on a recent version of Windows (even if you're using 2.2) you need to update the dev cert to the 3.0 version. You can either do this with the 3.0 SDK (and continue using 2.2) or by generating/exporting a cert on a machine that does have 3.0 and importing it on your Windows 10 machine.

Regardless, @poke, if you still have a concern I think it's appropriate to move to a separate issue. It may end up being related but there are a few different things getting tangled up here.

@hristijankiko can you export your ASP.NET Core development certificate and share it with us? Running the 3.0 dev cert --clean and --trust commands should have updated you to a cert that fixes this issue.

[hristijankiko]

@anurse I have tried cleaning the certificates manually and using the dotnet command line tools then generating new ones but both did not seem to have an effect.

This is my certificate details obtained using export from "Manage User Certificates" > Personal using certutil -v -dump

PFX protected to:
SID=VTMEL\xxx (S-1-5-21-3924087083-775290595-3317271348-4175)
================ Certificate 0 ================
================ Begin Nesting Level 1 ================
Element 0:
X509 Certificate:
Version: 3
Serial Number: 620bb96c5ab69a77
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Issuer:
    CN=localhost
  Name Hash(sha1): a0222faef31befba9f72cbcfbfc7cfb4f964ca0e
  Name Hash(md5): da9a129f5b3f0d51c3061e4fde49e4aa

 NotBefore: 24/09/2019 10:45 AM
 NotAfter: 23/09/2020 10:45 AM

Subject:
    CN=localhost
  Name Hash(sha1): a0222faef31befba9f72cbcfbfc7cfb4f964ca0e
  Name Hash(md5): da9a129f5b3f0d51c3061e4fde49e4aa

Public Key Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA
    Algorithm Parameters:
    05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
    0000  30 82 01 0a 02 82 01 01  00 f2 e8 7f 78 74 7d 59
    0010  8d 67 3e a5 c9 39 38 ae  43 91 b4 86 43 35 e6 6f
    0020  60 8e 72 b4 3e 34 b9 64  4b 8d db fc 11 00 ff 5a
    0030  eb 46 5c e2 ba 8a 9a d8  19 05 2d 5c 4f 74 49 e4
    0040  8b 57 84 22 bb 1e a5 3f  a8 46 53 78 25 d2 9d 23
    0050  90 59 85 44 d1 98 d8 0c  e9 46 30 52 a8 80 f7 9d
    0060  d8 5a 75 3f 0e 97 f9 69  ef 8b 8f 1e 49 a1 7b 3e
    0070  2d 28 8f fc 78 22 30 e5  af 8b 79 b6 16 6b 0c d1
    0080  33 b8 0c f3 5e 74 5e c5  25 bf 36 f4 16 b4 3a 74
    0090  81 07 38 ad a1 f9 8f e6  25 fe a2 6b a3 1a 19 c3
    00a0  95 94 50 6b 25 9f 6b 96  bd 76 3b 70 c4 72 74 8f
    00b0  ff 47 5c 4a 37 84 e5 a2  d7 6a e3 d0 06 35 f2 13
    00c0  e3 a5 b8 22 76 3b a6 4c  72 75 a6 82 2d ca 37 4a
    00d0  a5 20 a6 5c dd f8 ab e1  7f 7f 2c a3 9d 89 df 9b
    00e0  01 a8 d4 1c a1 ce b9 3a  04 67 cc 79 99 95 1f 93
    00f0  00 1b ea 98 c3 49 0b bc  13 29 e1 46 db 52 c3 66
    0100  b9 87 ab cc 37 38 a0 24  c5 02 03 01 00 01
Certificate Extensions: 5
    2.5.29.19: Flags = 1(Critical), Length = 2
    Basic Constraints
        Subject Type=End Entity
        Path Length Constraint=None

    2.5.29.15: Flags = 1(Critical), Length = 4
    Key Usage
        Digital Signature, Key Encipherment (a0)

    2.5.29.37: Flags = 1(Critical), Length = c
    Enhanced Key Usage
        Server Authentication (1.3.6.1.5.5.7.3.1)

    2.5.29.17: Flags = 1(Critical), Length = d
    Subject Alternative Name
        DNS Name=localhost

    1.3.6.1.4.1.311.84.1.1: Flags = 0, Length = 1

    0000  01                                                 .
0000: 01                                                ; .
================ DECODE ERROR! ================

Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Signature: UnusedBits=0
    0000  58 4d 71 c2 37 d8 90 48  df 6a c1 05 d4 5f fc 8e
    0010  a5 e2 92 38 3b 5f 9b 20  81 d1 a0 cf a7 d6 24 b4
    0020  36 38 26 dc 13 d6 d6 d6  99 fc 5d 70 00 cd d9 7c
    0030  72 57 a7 03 20 d1 80 33  f2 ce 68 a2 e7 5a b6 83
    0040  b2 24 e4 2c a8 26 8c c2  8c 67 01 5b 9d 87 a7 69
    0050  20 6a 76 e7 32 da e6 60  06 28 f8 23 48 b9 cf 70
    0060  ca 51 49 be 12 15 37 b7  f8 65 bb 9b 73 fd 14 1e
    0070  fe 52 4e 5d c5 6b 0d 9c  c9 54 8a 7f 3d 12 53 53
    0080  1c 7c 82 a0 76 05 bb 6b  38 e3 41 00 88 5f 0f c2
    0090  2d d3 bb 74 fa 23 4a 6f  a5 35 78 c6 d2 38 24 c0
    00a0  ce e7 25 aa 60 82 d2 88  18 bf b3 db 3a 91 e0 a4
    00b0  5f e2 f1 cf f7 b2 3b 70  cc f3 73 d7 36 8b 0a ab
    00c0  ee 1b c4 66 c2 d6 86 d9  42 f5 14 48 d1 30 3f 93
    00d0  e9 2f 9d ba 46 ed 5d 61  70 ab 72 1e ce dd 4c f4
    00e0  b5 85 55 56 a2 07 08 53  94 ea 34 90 78 2b 55 19
    00f0  dc 71 db 57 d3 a9 ac cc  19 cb 15 d0 de 44 52 36
Signature matches Public Key
Root Certificate: Subject matches Issuer
Key Id Hash(rfc-sha1): 6fdb852051db876c1abeff9a16604c2dfa3f6c3b
Key Id Hash(sha1): cf846bf3dd632c361852aa25a6e3a06247011785
Key Id Hash(bcrypt-sha1): 8e77f8abc40df860775f9066295424c614cf4d67
Key Id Hash(bcrypt-sha256): d0f7e1ba02e9570ba6039a2161908c021e42ab6e330f09b82cc8e79b136ac8d6
Key Id Hash(md5): ddba480784b612cd432e70779eb85d97
Key Id Hash(sha256): 6c1515650b114cf8f8a7b596d9944bb00d0d9617bfc274ce1593b4dfd8f4a225
Key Id Hash(pin-sha256): CkQkok+XHyzA3RxibjH6FEy+qtaXWC9AsBXoGtA8ogQ=
Key Id Hash(pin-sha256-hex): 0a4424a24f971f2cc0dd1c626e31fa144cbeaad697582f40b015e81ad03ca204
Cert Hash(md5): 16136c2fbaf5e09667e2a63dd0e7cef7
Cert Hash(sha1): 0ae998a78844b434894962996d1be86bab3cf3d9
Cert Hash(sha256): 8091ae4f75338a555d94c7e20bd1528bc3eb88459dfda0d7047bcdb1f6158fc6
Signature Hash: 04c50b99b4cc575423556092e69fc2b216ba43d471d7d4708635f462e45d4114
----------------  End Nesting Level 1  ----------------

  CERT_KEY_IDENTIFIER_PROP_ID(20):
    cf846bf3dd632c361852aa25a6e3a06247011785

  CERT_MD5_HASH_PROP_ID(4):
    16136c2fbaf5e09667e2a63dd0e7cef7

  CERT_SHA1_HASH_PROP_ID(3):
    0ae998a78844b434894962996d1be86bab3cf3d9

  CERT_KEY_CONTEXT_PROP_ID(5):
    hNCryptKey = 0000021EDDF30830
    KeySpec = ffffffff (-1) -- CERT_NCRYPT_KEY_SPEC

  CERT_FRIENDLY_NAME_PROP_ID(11):
    ASP.NET Core HTTPS development certificate

  CERT_ACCESS_STATE_PROP_ID(14):
  AccessState = 0

  Provider = Microsoft Software Key Storage Provider
  ProviderType = 0
  RSA
  Export Policy = 1
    NCRYPT_ALLOW_EXPORT_FLAG -- 1
  Algorithm Group: RSA
  Algorithm Name: RSA
  Length: 2048 (0x800)
  Lengths:
    dwMinLength = 512 (0x200)
    dwMaxLength = 16384 (0x4000)
    dwIncrement = 8 (0x8)
    dwDefaultLength = 1024 (0x400)
  Block Length: 256 (0x100)
  Export Policy: 1 (0x1)
    NCRYPT_ALLOW_EXPORT_FLAG -- 1

  Key Usage: 16777215 (0xffffff)
    NCRYPT_ALLOW_DECRYPT_FLAG -- 1
    NCRYPT_ALLOW_SIGNING_FLAG -- 2
    NCRYPT_ALLOW_KEY_AGREEMENT_FLAG -- 4
    NCRYPT_ALLOW_KEY_IMPORT_FLAG -- 8
    NCRYPT_ALLOW_ALL_USAGES -- ffffff (16777215)

  Virtual Iso: 0 (0x0)
  Per Boot Key: 0 (0x0)
  Key Usage = ffffff (16777215)
    NCRYPT_ALLOW_DECRYPT_FLAG -- 1
    NCRYPT_ALLOW_SIGNING_FLAG -- 2
    NCRYPT_ALLOW_KEY_AGREEMENT_FLAG -- 4
    NCRYPT_ALLOW_KEY_IMPORT_FLAG -- 8
    NCRYPT_ALLOW_ALL_USAGES -- ffffff (16777215)
Private key is NOT plain text exportable
Encryption test passed
CertUtil: -dump command completed successfully.

And this is the one from "Trusted Root Certification Authorities"

X509 Certificate:
Version: 3
Serial Number: 620bb96c5ab69a77
    77 9a b6 5a 6c b9 0b 62
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Issuer:
    CN=localhost
    [0,0]: CERT_RDN_PRINTABLE_STRING, Length = 9 (9/64 Characters)
        2.5.4.3 Common Name (CN)="localhost"

        6c 6f 63 61 6c 68 6f 73  74                        localhost

        6c 00 6f 00 63 00 61 00  6c 00 68 00 6f 00 73 00   l.o.c.a.l.h.o.s.
        74 00                                              t.

  Name Hash(sha1): a0222faef31befba9f72cbcfbfc7cfb4f964ca0e
  Name Hash(md5): da9a129f5b3f0d51c3061e4fde49e4aa

 NotBefore: 24/09/2019 10:45 AM
 NotAfter: 23/09/2020 10:45 AM

Subject:
    CN=localhost
    [0,0]: CERT_RDN_PRINTABLE_STRING, Length = 9 (9/64 Characters)
        2.5.4.3 Common Name (CN)="localhost"

        6c 6f 63 61 6c 68 6f 73  74                        localhost

        6c 00 6f 00 63 00 61 00  6c 00 68 00 6f 00 73 00   l.o.c.a.l.h.o.s.
        74 00                                              t.

  Name Hash(sha1): a0222faef31befba9f72cbcfbfc7cfb4f964ca0e
  Name Hash(md5): da9a129f5b3f0d51c3061e4fde49e4aa

Public Key Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA
    Algorithm Parameters:
    05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
    0000  30 82 01 0a 02 82 01 01  00 f2 e8 7f 78 74 7d 59
    0010  8d 67 3e a5 c9 39 38 ae  43 91 b4 86 43 35 e6 6f
    0020  60 8e 72 b4 3e 34 b9 64  4b 8d db fc 11 00 ff 5a
    0030  eb 46 5c e2 ba 8a 9a d8  19 05 2d 5c 4f 74 49 e4
    0040  8b 57 84 22 bb 1e a5 3f  a8 46 53 78 25 d2 9d 23
    0050  90 59 85 44 d1 98 d8 0c  e9 46 30 52 a8 80 f7 9d
    0060  d8 5a 75 3f 0e 97 f9 69  ef 8b 8f 1e 49 a1 7b 3e
    0070  2d 28 8f fc 78 22 30 e5  af 8b 79 b6 16 6b 0c d1
    0080  33 b8 0c f3 5e 74 5e c5  25 bf 36 f4 16 b4 3a 74
    0090  81 07 38 ad a1 f9 8f e6  25 fe a2 6b a3 1a 19 c3
    00a0  95 94 50 6b 25 9f 6b 96  bd 76 3b 70 c4 72 74 8f
    00b0  ff 47 5c 4a 37 84 e5 a2  d7 6a e3 d0 06 35 f2 13
    00c0  e3 a5 b8 22 76 3b a6 4c  72 75 a6 82 2d ca 37 4a
    00d0  a5 20 a6 5c dd f8 ab e1  7f 7f 2c a3 9d 89 df 9b
    00e0  01 a8 d4 1c a1 ce b9 3a  04 67 cc 79 99 95 1f 93
    00f0  00 1b ea 98 c3 49 0b bc  13 29 e1 46 db 52 c3 66
    0100  b9 87 ab cc 37 38 a0 24  c5 02 03 01 00 01
Certificate Extensions: 5
    2.5.29.19: Flags = 1(Critical), Length = 2
    Basic Constraints
        Subject Type=End Entity
        Path Length Constraint=None

    0000  30 00                                              0.
0000: 30 00                                     ; SEQUENCE (0 Bytes)

    2.5.29.15: Flags = 1(Critical), Length = 4
    Key Usage
        Digital Signature, Key Encipherment (a0)

    0000  03 02 05 a0                                        ....
0000: 03 02                                     ; BIT_STRING (2 Bytes)
0002:    05
0003:    a0

    2.5.29.37: Flags = 1(Critical), Length = c
    Enhanced Key Usage
        Server Authentication (1.3.6.1.5.5.7.3.1)

    0000  30 0a 06 08 2b 06 01 05  05 07 03 01               0...+.......
0000: 30 0a                                     ; SEQUENCE (a Bytes)
0002:    06 08                                  ; OBJECT_ID (8 Bytes)
0004:       2b 06 01 05 05 07 03 01
               ; 1.3.6.1.5.5.7.3.1 Server Authentication

    2.5.29.17: Flags = 1(Critical), Length = d
    Subject Alternative Name
        DNS Name=localhost
    AltName: 1 entries:
    AltName[0] CERT_ALT_NAME_DNS_NAME: "localhost"

    0000  30 0b 82 09 6c 6f 63 61  6c 68 6f 73 74            0...localhost
0000: 30 0b                                     ; SEQUENCE (b Bytes)
0002:    82 09                                  ; CONTEXT_SPECIFIC[2] (9 Bytes)
0004:       6c 6f 63 61 6c 68 6f 73  74                       ; localhost

    1.3.6.1.4.1.311.84.1.1: Flags = 0, Length = 1
    CryptFormatObject: No built-in formatting support

    0000  01                                                 .
0000: 01                                                ; .
================ DECODE ERROR! ================

Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Signature: UnusedBits=0
    0000  58 4d 71 c2 37 d8 90 48  df 6a c1 05 d4 5f fc 8e
    0010  a5 e2 92 38 3b 5f 9b 20  81 d1 a0 cf a7 d6 24 b4
    0020  36 38 26 dc 13 d6 d6 d6  99 fc 5d 70 00 cd d9 7c
    0030  72 57 a7 03 20 d1 80 33  f2 ce 68 a2 e7 5a b6 83
    0040  b2 24 e4 2c a8 26 8c c2  8c 67 01 5b 9d 87 a7 69
    0050  20 6a 76 e7 32 da e6 60  06 28 f8 23 48 b9 cf 70
    0060  ca 51 49 be 12 15 37 b7  f8 65 bb 9b 73 fd 14 1e
    0070  fe 52 4e 5d c5 6b 0d 9c  c9 54 8a 7f 3d 12 53 53
    0080  1c 7c 82 a0 76 05 bb 6b  38 e3 41 00 88 5f 0f c2
    0090  2d d3 bb 74 fa 23 4a 6f  a5 35 78 c6 d2 38 24 c0
    00a0  ce e7 25 aa 60 82 d2 88  18 bf b3 db 3a 91 e0 a4
    00b0  5f e2 f1 cf f7 b2 3b 70  cc f3 73 d7 36 8b 0a ab
    00c0  ee 1b c4 66 c2 d6 86 d9  42 f5 14 48 d1 30 3f 93
    00d0  e9 2f 9d ba 46 ed 5d 61  70 ab 72 1e ce dd 4c f4
    00e0  b5 85 55 56 a2 07 08 53  94 ea 34 90 78 2b 55 19
    00f0  dc 71 db 57 d3 a9 ac cc  19 cb 15 d0 de 44 52 36
Signature matches Public Key
Root Certificate: Subject matches Issuer
Key Id Hash(rfc-sha1): 6fdb852051db876c1abeff9a16604c2dfa3f6c3b
Key Id Hash(sha1): cf846bf3dd632c361852aa25a6e3a06247011785
Key Id Hash(bcrypt-sha1): 8e77f8abc40df860775f9066295424c614cf4d67
Key Id Hash(bcrypt-sha256): d0f7e1ba02e9570ba6039a2161908c021e42ab6e330f09b82cc8e79b136ac8d6
Key Id Hash(md5): ddba480784b612cd432e70779eb85d97
Key Id Hash(sha256): 6c1515650b114cf8f8a7b596d9944bb00d0d9617bfc274ce1593b4dfd8f4a225
Key Id Hash(pin-sha256): CkQkok+XHyzA3RxibjH6FEy+qtaXWC9AsBXoGtA8ogQ=
Key Id Hash(pin-sha256-hex): 0a4424a24f971f2cc0dd1c626e31fa144cbeaad697582f40b015e81ad03ca204
Cert Hash(md5): 16136c2fbaf5e09667e2a63dd0e7cef7
Cert Hash(sha1): 0ae998a78844b434894962996d1be86bab3cf3d9
Cert Hash(sha256): 8091ae4f75338a555d94c7e20bd1528bc3eb88459dfda0d7047bcdb1f6158fc6
Signature Hash: 04c50b99b4cc575423556092e69fc2b216ba43d471d7d4708635f462e45d4114
CertUtil: -dump command completed successfully.

[analogrelay]

1.3.6.1.4.1.311.84.1.1: Flags = 0, Length = 1

    0000  01

🤔 This is the our "Extension" in the certificate that indicates the version and the value (01) is the correct version for 3.0 (the previous version is called version 0 and had a completely different content), which should have this fix.

I think the next thing to check is that this certificate is precisely the one Kestrel is selecting. Perhaps there's an issue with the selection logic. Are there any other certificates in your stores for the subject name localhost? If you have IIS Express installed, you might see one with the friendly name "IIS Express Development Certificate". The warning sign here would be if you have two certificates labelled "ASP.NET Core HTTPS development certificate"

Here's an example of the certificate manager UI from my machine:

It would also be useful to confirm what certificate the browser is receiving (you can usually do this through the dev tools) and compare the thumbprint of the certificate the browser has with the ones in the cert store to identify which one is in use.

[hristijankiko]

Sorry for the late reply @anurse , I was out of office until today. I checked the certificate that gets received by the browser and it seems to be the correct one.

I do not have IIS certificate under Personal Certificates and I only have the .NET Core one.

Under Trusted Root Certification Authorities I do have the IIS certificate as well.

IIS Certificate:

Please let me know if you need any additional information

[analogrelay]

@hristijankiko That certificate info dialog looks like the Firefox one, and Firefox doesn't normally participate in the Windows cert store. Can you clarify which browsers are showing which error? As far as we're aware, the ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY error occurs in Chrome when using the old certificate. We've not encountered it with Firefox, which uses a somewhat-different network stack and certificate store.

[hristijankiko]

@anurse I used Firefox just to get the certificate which is used for the connection because in Chrome (And in Firefox it was only shown the first time, as once you proceed it goes directly to the error page and skips the warning page), it is not shown in the dev tools, but regardless of which browser I use the error is same.
Brave (Chromium):

Firefox

Edge dev

[hristijankiko]

@anurse Sent

[analogrelay]

Hrm, I haven't received anything yet (and I would expect to get it within this time window).

[Parrawk]

I ran into the same problem "This site can't be reached" with the same error "ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY" when using Windows 8.1 Enterprise.

Setting the Kestrel Protocol to "Http1" in the appsettings solved the issue on Chrome, but Firefox still doesn't recognize the self-signed cert, I don't mind since it opens the web app normally after ignoring the warning.

Windows ciphers can only be adjusted in the registry.

Disabling HTTP2 in config is easier. Here's an example that disables HTTP/1.1.
https://github.com/aspnet/AspNetCore/blob/0a26524af0121e9db4ad1f3a6f98e33c3b52cdbd/src/ProjectTemplates/Web.ProjectTemplates/content/GrpcService-CSharp/appsettings.json#L9-L13

Thank you!

[analogrelay]

Setting the Kestrel Protocol to "Http1" in the appsettings solved the issue on Chrome

This disables HTTP/2, and the "INADEQUATE_TRANSPORT_SECURITY" issue is an HTTP/2-specific issue, so while that works, it's not really a solution.

Firefox still doesn't recognize the self-signed cert

This is an unrelated issue. Our dev cert process doesn't install the cert into the Firefox store (Firefox uses a different certificate store from Windows), so it's expected that it's not trusted until you explicitly trust it.

[Parrawk]

OK, I see now that hristijankiko's issue is happening in W10, but for W8.1 users the only options are to either disable HTTP/2 or manually set the TLS ciphers (which I can't do on this machine right now). And since I'm running a web server with WServer 2012 R2 I won't even be able to use HTTP/2 anyway, so I'm disabling it until I get an upgrade (and I know that won't happen soon).

My main concern is that this is not mentioned in the tutorial, so as I was following it I couldn't even get through the "Get Started" part of the MVC section without running into this problem (I know very few people are still on W8.1 but we are on "extended support").

I know it's a different problem, but those two answers by Tratcher helped me to get the template running, I only need to remember to enable HTTP/2 when deploying the app to a new server, or just move to a Linux VM for dev and prod.

[hristijankiko]

@anurse This is the email I sent it to.

Could it be a security thing or maybe it went to junk folder or something?

[analogrelay]

I bet it was suppressed due to the file extensions being considered unsafe. I'd suggest either a) sending a download link from OneDrive/DropBox/Google Drive/etc.-like service or b) renaming the files to have different file extensions.

[hristijankiko]

@anurse Emailed through a Dropbox link

[codecoded]

Hey,

O/S: Win 10 Enterprise
Browser: Edge Beta & Chrome (tried completely new install)

I seem to have this issue after updating to .net core 3.0 but slightly different variation. But thought I'd just mention my experience in case it gives clue to where the problem maybe.

On updating, I was asked to re-install the local certs, so I did for my .net core webapi.
When I then tested the SPA client site, I saw in the browser dev tools the OP's issue

I then try to visit an endpoint in the browser directly and sure enough, says NET::ERR_CERT_AUTHORITY_INVALID.

On reading this thread, I double checked the cert being served, and it's a certificate I cannot find anywhere on my machine. I have deleted all my localhost certs from the certificate console, reinstalled new ones etc several times, but the browser is always serving an old cert.

Now, here's where I get confused. I load up another WebApi project mine that's still dotnet 2.2, and in the same browser session, go visit an API endpoint and it picks up the new certs perfectly fine and it all works.

Swapping the projects back again and hitting an identical endpoint e.g . https://localhost:5001/api/system/info is in both projects, the .net 3.0 gives me invalid cert again!

Like I say, this is slightly different to the OP as he seems to getting the correct cert and still having this issue

[Tratcher]

@codecoded are you using containers for any of this? The dev cert gets copied to temp locations accessible from containers.

[analogrelay]

To circle back to the original issue. @hristijankiko sent us some great details (including a Wireshark trace that was very helpful). We identified that the server was selecting a cipher suite on the HTTP/2 block-list due to "inadequate security". It turns out this was a machine-level configuration issue caused by upgrading from earlier Windows versions.

The fix was to manually configure the TLS cipher suites to match the new Windows 10 defaults (see https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1903). It's curious that this was necessary even though @hristijankiko was using Windows 10 v1903 but we will check in on this internall.

No further action on the original issue is needed in ASP.NET Core.

Like I say, this is slightly different to the OP as he seems to getting the correct cert and still having this issue

@codecoded It's much better to just post a new issue even if it seems related. Let us handle the process of marking it as a duplicate ;). Unless you're very confident it's the same cause, go ahead and create a new issue, we don't mind a little duplication and it's easier for us to keep separate issues separate.

I'm going to close this as the original issue is resolved, please move discussions of other issues to new threads.

[simeyla]

WOW! What a thread!

I'm doing this in development for an angular app. So if your config look anything like mine all I did to get it working was add the Protocols option.

.ConfigureKestrel((context, options) =>
                {
                    // development options for kestrel
                    if (context.HostingEnvironment.IsDevelopment())
                    {
                        options.Listen(IPAddress.Any, 5000);  // http:localhost:5000
                        options.Listen(IPAddress.Any, 44300, listenOptions =>
                        {
                            listenOptions.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http1;   // force http1 during dev.

                            listenOptions.UseHttps(@"S:\WORK\SSL\example.com.pfx", "1234567", httpsOptions =>
                            {
                                httpsOptions.SslProtocols = System.Security.Authentication.SslProtocols.Tls;
                            });
                        });
                    }
                });

[jhudsoncedaron]

What's the chance of getting a Windows hotfix for this? The cipher suite declarations in these OSes are essentially corrupted.

[Tratcher]

@jhudsoncedaron you'll need to contact Microsoft Support about that.

[analogrelay]

What's the chance of getting a Windows hotfix for this? The cipher suite declarations in these OSes are essentially corrupted.

Actually, we traced it further and found that generally it's IT policies setting these incorrect TLS suite orders. Upgrades should work fine. If you're seeing this incorrect Cipher Suite ordering (i.e. not matching the list in https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1903) please check with your IT administrators (if any) first to see if they've modified them.

If you see this incorrect ordering but don't have any IT policies in place, then contact Microsoft Support.

And finally, if you see correct cipher suite ordering but are still having trouble with ASP.NET Core (or if you have other questions) please feel free to open a new bug!

[StrangeWill]

It's curious that this was necessary even though @hristijankiko was using Windows 10 v1903 but we will check in on this internall.

I'm interested in this, I have a machine on a (very nearly) clean 2016 domain in a lab and am experiencing the same problem, also on v1903.

First the list was unset, so I set it to the defaults, no go.
Then I hard-set it to the list provided on the linked doc (https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-10-v1903) which is also a pain to copy/paste them all, that was also a no-go.

Considering this is failing on a default I'm kind of worried to even touch it.

[jhudsoncedaron]

@anurse : Observed on out-of-the-box Windows Server 2012 R2 with no policy pushed to it.

[Tratcher]

@jhudsoncedaron Is that as the client or server? 2012 R2 pre-dates Win10 and direct Http/2 support. It can be made to work by tweaking the ciphers list.

[jhudsoncedaron]

@Tratcher : It's on the server, and causes complete failure of the Kestrel server on https with a default Kestrel configuration. We didn't actually check but we're reasonably certain the dotnet new mvc project doesn't work. Expected a valid cipher list on the out-of-the-box Windows install; got a bad cipher list. Even Edge doesn't recognize the cipher names, so we just concluded the server's cipher list is corrupted on install. Kestrel could have checked and found no ciphers for http 2 and turned it off but this really is a Windows problem.

[Tratcher]

Yeah, in hindsight Kestrel shouldn't have enabled HTTP/2 by default on 2012 R2, only on 2016 and Win10. @anurse that still might be worth changing since it's hard to make work out of the box. I'll open a specific issue for it.

[jhudsoncedaron]

@Tratcher : I'd like to know how you plan to work around the fact that Environment.OSVersion returns the wrong value. In our debate we came up with checking for the presence of the api-ms-win-*.dlls in the current directory, which works, but is specific to us. (The installer detects Windows 10 in native code and won't drop those dlls on Windows 10 or server 2019.)

[Tratcher]

Environment.OSVersion returns the correct version if you enable Win10 support in the manifest.
https://stackoverflow.com/a/33328814/2588374

[jhudsoncedaron]

@Tratcher : I am aware of that. The default project template does not set that manifest parameter. The primary difficulty involved is when a library (rather than an executable) has to care, and Kestrel is a library.

[Tratcher]

@jhudsoncedaron good point. Moving this part of the discussion to #16811.