Err_Ssl Key_Usage Incompatible !

ec · 2024-08-27 13:53:28

Hi,

Browsers return ERR_SSL_KEY_USAGE_INCOMPATIBLE when accessing any resource with a self-signed certificate, on Windows, for example:
https://192.168.0.128:7799

What is wrong ?

Last edited by ec (2024-08-27 18:25:01)

ab · 2024-08-27 15:11:55

Did you include the self-signed certificate to the browser?

Did you set the proper key usage to the certificate?

Did you put the exact same IP as CN for the certificate?

ec · 2024-08-27 18:17:42

Hi Ab,

I'm using InitNetTlsContextSelfSignedServer. It was working perfectly since my first tests. Now, it only works in mormot2 connections (wss client, for example) to mormot2 (wss server, for example), and the following exception occurs when connected via browser (https, or wss):

:00007FFFD9D0FABC ; C:\Windows\System32\KERNELBASE.dll
System._RaiseAtExcept(???,???)
System._RaiseExcept(???)
mormot.net.sock.TSChannelNetTls.ESChannelRaiseLastError('''¼'#0#0#0#0#0'&'#3#9'€'#0#0#0#0#0#0#0#0#3#0#0#0'xy’'#7#0#0#0#0#$1C#1#1#0'&'#3#9'€ày’'#7#0#0#0#0'¨&¼'#0#0#0#0#0'€¼Á'#4#0#0#0#0'Õ''¼'#0#0#0#0#0'&'#3#9'€'#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0'P'#$B'¼'#0#0#0#0#0'ðD»'#4#0#0#0#0#8'ÿ’'#7#0#0#0#0'Àz’'#7#0#0#0#0#0#0#0#0#0#0#0#0'<'#4#0#0#0#0#0#0'ðD»'#4'8J'#0#0'PNî'#6#0#0#0#0#0#0#0#0'&'#3#9'€`z’'#7#0#0#0#0' !¼'#0#0#0#0#0'€¼Á'#4#0#0#0#0'Â!¼'#0#0#0#0#0#0#0#0#0#0#0#0#0'P"ñ'#6#0#0,2148074278)
mormot.net.sock.TSChannelNetTls.CheckSEC_E_OK('''¼'#0#0#0#0#0'&'#3#9'€'#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0'P'#$B'¼'#0#0#0#0#0'ðD»'#4#0#0#0#0#8'ÿ’'#7#0#0#0#0'Àz’'#7#0#0#0#0#0#0#0#0#0#0#0#0'<'#4#0#0#0#0#0#0'ðD»'#4'8J'#0#0'PNî'#6#0#0#0#0#0#0#0#0'&'#3#9'€`z’'#7#0#0#0#0' !¼'#0#0#0#0#0'€¼Á'#4#0#0#0#0'Â!¼'#0#0#0#0#0#0#0#0#0#0#0#0#0'P"ñ'#6#0#0#0#0'Àz’'#7#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0'°¼Á'#4#0#0#0#0#0#0#0#0#0#0#0#0#$90'¿'#$12#1#0#0#0#0'Àz’'#7#0#0#0#0#0#0#0#0#0#0,-2146893018)
mormot.net.sock.TSChannelNetTls.HandshakeLoop
mormot.net.sock.TSChannelNetTls.AfterAccept($43C,(True, True, True, True, False, False, False, '', nil, '', ),???,nil {''})
mormot.net.async.TAsyncServer.OnFirstReadDoTls($4B93F30)
mormot.net.async.TPollAsyncConnection.OnFirstRead($4BDBFB0)
mormot.net.async.TPollAsyncSockets.ProcessRead($4C66CD0,1152921504686096176)
mormot.net.async.TAsyncConnectionsThread.Execute
System.Classes.ThreadProc($4C66CD0)
System.ThreadWrapper($4BB44E0)
:00007FFFDADE257D ; C:\Windows\System32\KERNEL32.DLL
:00007FFFDC82AF28 ; ntdll.dll

...
InitNetTlsContextSelfSignedServer(FTls, caaRS256);
FTls.IgnoreCertificateErrors := True;
...
FWsServer :=
TWebSocketAsyncServer.Create(
Target, Nil, Nil, 'Acceptor', FOuAccepts, 30000, [
hsoNoStats, hsoEnableTls,
hsoNoXPoweredHeader,
hsoHeadersInterning,
hsoCreateSuspended,
hsoThreadSmooting ]);
...
FWsServer.Start;
FWsServer.WaitStarted(10, @FTls);
...

Last edited by ec (2024-08-27 18:47:35)

ab · 2024-08-28 12:02:25

Such a self-side certificate will be rejected by the browser for sure, because it does NOT know how to validate it.

FTls.IgnoreCertificateErrors := True;

does not make any sense on server side.

Please don't put so much confused content in the forum thread.
Your stack trace is just buggy and does not show anything interresting, since the shown parameters are clearly wrong.

What is the exact exception message on the server side?
What is the error on the browser side?

ec · 2024-08-28 12:15:23

Sorry for the inconvenience, ab. The code snippet was just intended to illustrate how I was doing it on both sides (client and server). The exception that is appearing on the server side is:
Project ecentric.exe raised exception class ESChannel with message '<>: HandshakeStep returned 80090326 [SEC_E_ILLEGAL_MESSAGE], System Error 87 [ERROR_INVALID_PARAMETER]'.

The error at the browser side is:
ERR_SSL_KEY_USAGE_INCOMPATIBLE

Last edited by ec (2024-08-28 12:25:14)

ec · 2024-08-28 13:47:42

Ab, with curl, there is no exception at server side:

C:\Tools\curl\bin>curl -v -k "https://192.168.0.128:7799"
* Trying 192.168.0.128:7799...
* Connected to 192.168.0.128 (192.168.0.128) port 7799
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
* subject: CN=127.0.0.1
* start date: Jul 6 20:15:22 2022 GMT
* expire date: Jul 3 20:15:22 2032 GMT
* issuer: CN=127.0.0.1
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Certificate level 0: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET / HTTP/1.1
> Host: 192.168.0.128:7799
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Server: ecentric.I11
< Content-Length: 0
<
* Connection #0 to host 192.168.0.128 left intact

Last edited by ec (2024-08-28 13:48:13)

ab · 2024-08-28 13:58:06

My guess is that the browser does not accept the certificate, so it shut down the connection.

Whereas a mORMot client or a curl client continue with an unknown certificate.

Which version of Windows are you using on the server side?
I would rather use OpenSSL (and Linux;) if possible fr the server side.

ec · 2024-08-28 14:02:54

I'm using Windows 11 on the server side. Until a few days ago, this exception was not occurring. Now the browser's websocket client causes this exception on the server!

ab · 2024-08-28 14:04:48

Maybe it is related to TLS 1.3 support on SChannel, included a few days/weeks ago.

ec · 2024-08-28 15:12:58

Ab, I also tested it this way, and the exception continues to occur on the server side, in any version of TLS

PS C:\Windows\system32> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls11
PS C:\Windows\system32> Invoke-WebRequest -Uri https://192.168.0.128:7799

PS C:\Windows\system32> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
PS C:\Windows\system32> Invoke-WebRequest -Uri https://192.168.0.128:7799

PS C:\Windows\system32> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls13
PS C:\Windows\system32> Invoke-WebRequest -Uri https://192.168.0.128:7799

ab · 2024-08-28 15:56:12

Yes, make sense. Curl had no problem with your server TLS 1.3, so I guess it was fine.

So I still guess you need to try with a proper certificate, from Let's Encrypt, or self-signed but known by the client browser.

What does Invoke-WebRequest respond?

ec · 2024-08-28 16:06:24

PS C:\Windows\system32> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls13
PS C:\Windows\system32> Invoke-WebRequest -Uri https://192.168.0.128:7799
Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the
SSL/TLS secure channel. At line:1 character:1 + Invoke-WebRequest -Uri https://192.168.0.128:7799 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo: InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc eption + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Last edited by ec (2024-08-28 16:09:17)

ab · 2024-08-29 07:03:19

I still guess that it does not know anything about this certificate, so it rejects it.

ec · 2024-08-29 10:26:53

Ok, I'll test as suggested.

I tried using openssl but I'm getting the following error:

[dcc64 Error] mormot.crypt.openssl.pas(879): E2250 There is no overloaded version of 'AlgoName' that can be called with these arguments
[dcc64 Error] mormot.crypt .openssl.pas(966): E2250 There is no overloaded version of 'AlgoName' that can be called with these arguments
[dcc64 Fatal Error] mor.wss.acceptor.pas(918): F2063 Could not compile used unit 'mormot. crypt.openssl.pas' Failed

ab · 2024-08-29 11:35:53

https://synopse.info/forum/viewtopic.ph … 052#p42052

ec · 2024-08-29 12:29:22

Ab, I did this (with and without openssl):

1. openssl genrsa -out private.key 2048
2. openssl req -new -key private.key -out request.csr
3. openssl x509 -req -days 365 -in request .csr -signkey private.key -out certificate.crt
4. I installed the certificate on Windows

When I use one of the ways:

...
FWsServer.WaitStarted(10, 'C:\Devel\eCentric-11\certificate\certificate.crt' , 'C:\Devel\eCentric-11\certificate\private.key');

Or

...
InitNetTlsContext(FTls, {server=}True, 'C:\Devel\eCentric-11\certificate\certificate.crt', 'C:\Devel\eCentric-11\certificate\private.key');
FWsServer .WaitStarted(10, @FTls);

Now the following exception is occurring:
Project ecentric.exe raised exception class ESChannel with message '<>: PFXImportCertStoreSEC_E_CERT_UNKNOWN returned 80090327 [SEC_E_CERT_UNKNOWN], System Error -2146885630 [Error during encryption operation or decoding]'.

Last edited by ec (2024-08-29 12:30:35)

ab · 2024-08-29 12:57:18

1) You need to install the certificate on the client system too, by definition.
2) You need to specify the 'web server' extended usage when you create the certificate.

ec · 2024-08-29 13:42:14

Ab, check this out:

I ran an additional step with openssl, as documented in TSChannelNetTls.AfterBind:

openssl pkcs12 -inkey private.key -in certificate.crt -export -out certificate.pfx

Using ...

InitNetTlsContext(FTls, True, 'C:\Devel\eCentric-11\certificate\certificate.pfx', 'C:\Devel\eCentric-11\certificate\private.key');

Or ...

FWsServer.WaitStarted(10, 'C:\Devel\eCentric-11\certificate\certificate.pfx', 'C:\Devel\eCentric-11\certificate\private.key');

And, ignoring the server-side exception...

It worked again!!!

The browser displays the usual warning:

Your connection is not private Attackers might be trying to steal your information from 192.168.0.128 (for example, passwords, messages, or credit cards). Learn more about this warning net::ERR_CERT_AUTHORITY_INVALID Turn on enhanced protection to get Chrome's highest level of security This server could not prove that it is 192.168.0.128; its security certificate is not trusted by your computer's operating system. This may be caused by a misconfiguration or an attacker intercepting your connection.

Proceed to 192.168.0.128 (unsafe).

And the websocket client (wss) also works.

The certificate has been deleted from Windows!!!

Working with or without openssl

Ab, in my understanding it doesn't work when we use InitNetTlsContextSelfSignedServer(FTls, Algo).

What do you think ?

Last edited by ec (2024-08-29 14:28:38)

ec · 2024-08-29 18:38:14

But, I think ignoring this exception may not be a good idea, things may not work correctly

ab · 2024-08-30 06:09:41

Anyway, it is difficult to help you because you don't put enough relevant information: either the information is partial, or it is without interest.
A minimal reproducible example, with an external link (not the code directly in this forum) is always better.

I think you did not use OpenSSL on the server side, but only SChannel.
When I wrote about using OpenSSL on the server side, I meant about defining the USE_OPENSSL conditional for the project, or even maybe FORCE_OPENSSL.
Then the server project will switch from the SChannel API to OpenSSL - if you have the proper libraries within the executable folder.

If you use SChannel, you are required to use a .pfx file.
Then it works.

A working HTTPS server is available in procedure THttpProxyServer.Start():

  // wait for actual server availability
  if hsoEnableTls in hso then
    if psoHttpsSelfSigned in fSettings.Server.Options then
      fServer.WaitStartedHttps
    else
      fServer.WaitStarted(30, @tls)
  else
    fServer.WaitStarted;

So I guess your code should use WaitStartedHttps, or at least follow its internal pattern, which deletes the temporary files.
Also note that you should not need to call

FWsServer.Start;

in your code.

ec · 2024-08-30 09:40:22

Ab, I apologize for the language barrier, and I thank you in advance for your attention.

I was able to identify the issue that caused confusion here. The conclusion is that when SChannel is used, the certificate generated by the call to InitNetTlsContextSelfSignedServer(FTls, Algo, {UsePreComputed=}TRUE) only works with mormot2, or curl, and is not valid and/or compatible with current browsers. However, when a .pfx certificate is used, and not the precomputed one, it works normally.

ec · 2024-09-09 13:43:46

In case anyone is interested, InitNetTlsContextSelfSignedServer works in Firefox too, with the pre-computed certificate.

mORMot Open Source

#1 2024-08-27 13:53:28

Err_Ssl Key_Usage Incompatible !

#2 2024-08-27 15:11:55

Re: Err_Ssl Key_Usage Incompatible !

#3 2024-08-27 18:17:42

Re: Err_Ssl Key_Usage Incompatible !

#4 2024-08-28 12:02:25

Re: Err_Ssl Key_Usage Incompatible !

#5 2024-08-28 12:15:23

Re: Err_Ssl Key_Usage Incompatible !

#6 2024-08-28 13:47:42

Re: Err_Ssl Key_Usage Incompatible !

#7 2024-08-28 13:58:06

Re: Err_Ssl Key_Usage Incompatible !

#8 2024-08-28 14:02:54

Re: Err_Ssl Key_Usage Incompatible !

#9 2024-08-28 14:04:48

Re: Err_Ssl Key_Usage Incompatible !

#10 2024-08-28 15:12:58

Re: Err_Ssl Key_Usage Incompatible !

#11 2024-08-28 15:56:12

Re: Err_Ssl Key_Usage Incompatible !

#12 2024-08-28 16:06:24

Re: Err_Ssl Key_Usage Incompatible !

#13 2024-08-29 07:03:19

Re: Err_Ssl Key_Usage Incompatible !

#14 2024-08-29 10:26:53

Re: Err_Ssl Key_Usage Incompatible !

#15 2024-08-29 11:35:53

Re: Err_Ssl Key_Usage Incompatible !

#16 2024-08-29 12:29:22

Re: Err_Ssl Key_Usage Incompatible !

#17 2024-08-29 12:57:18

Re: Err_Ssl Key_Usage Incompatible !

#18 2024-08-29 13:42:14

Re: Err_Ssl Key_Usage Incompatible !

#19 2024-08-29 18:38:14

Re: Err_Ssl Key_Usage Incompatible !

#20 2024-08-30 06:09:41

Re: Err_Ssl Key_Usage Incompatible !

#21 2024-08-30 09:40:22

Re: Err_Ssl Key_Usage Incompatible !

#22 2024-09-09 13:43:46

Re: Err_Ssl Key_Usage Incompatible !

Board footer