Mac RDP not able to connect to E5 wildcard

I am setting up a web server and Remote Desktop Server with a wildcard certificate from Let's Encrypt. I have one that currently is issued by "R3". The refreshed certificate is now issued by "E5". I can access the website with either certificate. The windows RDP clients can access the Remote Desktop server with the R3 or E5 certificate. However, I cannot access the Remote Desktop server with my Mac RDP client 10.9.8 on Mac 14.5 with the new E5 certificate. The Mac shows an error 0x3000066. Not sure if there is a way to clear out some stored certificate on the Mac RDP Client, or if there is something else going on. Everything appears to be working, but I don't know where to start troubleshooting this.

Probably in a Mac or Microsoft forum, as you aren't having any issue obtaining Let's Encrypt certificates, which is the primary focus here.

I don't know if this is relevant, but it is from a more relevant venue for the problem you are having.

3 Likes

My guess would be that the server isn't sending the complete certificate chain like it's supposed to. (Though I don't have any RDP certificate experience.) What ACME client gets the certificate, and how is it configured to install the certificate and chain on the server?

5 Likes

Linkp, the link asks the question, but no one has answered.
I'm not sure about the chain, considering the Windows version of the RDP isn't compaining about it nor is Safari on the Mac complaining about it.
I am using a mix of certbot and PowerShell. Certbot to request the certificate and then openssl to generate the pfx and p12

certbot certonly --manual -d mydomain.com,*.mydomain.com --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 -m user@mydomain.com --server https://acme-v02.api.letsencrypt.org/directory

1 Like

Also, what is the version of Windows Server?

Your cert is using an Elliptic Curve (ECDSA) based key instead of the RSA, and since Let's Encrypt recently changed their chains you will now be receiving a completely EC chain whereas before the higher part of the chain was RSA. This can affect compatibility, and old versions of Windows circa Server 2012 didn't have EC key support enabled by default in TLS (in the protocol and cipher suite combinations). IISCrypto is a good tool for seeing what you currently have enabled at the TLS level for the server.

The conventional tools for ACME RDP certs are win-acme, Certify The Web (which I develop) and Posh-ACME, all of which produce PFX but certbot would still work if your resulting PFX has a chain - you can right click on the PFX to open it in windows explorer and see the list of certs inside the archive, you should see your "leaf" cert for your own domain and you should see the intermediate that would lead to the root.

[Edit]

You can also test your RDP cert chain being presented to the client using openssl
openssl s_client -connect yourserver.domain.com:3389 -prexit

You're looking for the intermediate (E5 or E6) being included in the served chain becuase that leads to the trusted root ISRG Root X2 - you'll also ideally want to make sure the mac client trusts ISRG Root X2 at the os level: Chains of Trust - Let's Encrypt

4 Likes

Well, it might be that your scripting to load it into a pfx and put on your server isn't loading the whole chain. Can you share what script you're running to do that? Are you running certbot on Windows? They don't support certbot on Windows anymore.

Even if it's not related to your problem, you'd probably find it easier to use a Windows-based client. Posh-ACME may be a good choice if you're a Powershell fan, and you may be able to automate things rather than what looks like a manual process now.

3 Likes

This is on Windows Server 2022 with Remote Desktop Server 2022
Cert.ps1.txt (4.1 KB)
on the certification path, it shows ISRG Root X1->E5->MyDomain.com
I'm not sure about your openssl command
18330000:error:8000274C:system library:BIO_connect:Unknown error:..\crypto\bio\bio_sock2.c:178:calling connect()
18330000:error:10000067:BIO routines:BIO_connect:connect error:..\crypto\bio\bio_sock2.c:180:
connect:errno=0

no peer certificate available

No client certificate CA names sent

SSL handshake has read 0 bytes and written 0 bytes
Verification: OK

New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

attached is the report if I show port 80
CONNECTED(000001D8)
34290000:error:0A0000C6:SSL routines:tls_get_more_records:packet length too long:..\ssl\record\methods\tls_common.c:649:
34290000:error:0A000139:SSL routines::record layer failure:..\ssl\record\rec_layer_s3.c:646:

no peer certificate available

No client certificate CA names sent

SSL handshake has read 5 bytes and written 333 bytes
Verification: OK

New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)


no peer certificate available

No client certificate CA names sent

SSL handshake has read 505 bytes and written 333 bytes
Verification: OK

New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Thanks, my example openssl command used port 3389 with an example domain (I don't know your real rdp host name) which as it turns out is also a real domain. You need to substitute with your own domain and RDP port. So to rephrase it:

openssl s_client -connect <your server fully qualified name>:<your rdp port> -prexit

You can't test port 80 because there is no TLS enabled service on port 80 (just http), instead that would normally be port 443 on a server running an web server, which not all servers do.

Ultimately though I think that you only need to import your full chain (drop the -certfile) like. Note I'm not an openssl whizz:
openssl.exe pkcs12 -in fullchain.pem -inkey privkey.key -export -out output.pfx

When windows clients encounter an incomplete chain they can resolve it themselves using their own path validation (which includes resolving intermediates and downloading missing roots it might need from microsoft, group policy permitting). Other operating systems tend not to do that.

As an aside I note your choice of PFX /p12 algorithms which are the newer combination of AES-256-CBC and SHA256, whereas standard old fashioned (and most compatible) but I'm not sure if this would make any difference to a typical client app and I've only see it be a problem on older versions of Windows Server. Legacy PFXs use (this is me attempting to convert into openssl speak):
Cert alg: pbeWithSHA1And3-KeyTripleDES-CBC
Key alg: pbeWithSHA1And40BitRC2-CBC

For anyone else trying to achieve the same, you can also achieve all this (deploying to the local rdp gateway) in Certify The Web by adding the Deploy To RDP Gateway Service task under Tasks. That effectively runs this script: certify-plugins/src/DeploymentTasks/Core/Providers/Assets/RDPGatewayServices.ps1 at development · webprofusion/certify-plugins · GitHub

5 Likes

so I swapped the chain.pem with fullchain.pem (I don't use the P12 on this server) and it hasn't resolved the issue, still getting the 66 error. Yeah, I goofed on the 80 vs 443 (a little panicked with the good cert expiring tomorrow). Attached is the diagnostics of the 2 certificates using 443 and 3389
SSL Diag.txt (12.3 KB)

So your port 443 certificate is good (IIS serving https, using the chain Leaf > E5 > ISRG Root X1) but your port 3389 service just isn't using a certificate at all currently. I'd suggest first setting it manually in the RD Gateway management console in Windows rather than scripting it, just until you're sure it works.Make sure it's working for windows clients first.

I'm still not sure if you might be seeing a macOS RDP compatibility issue due to the EC keyed intermediate rather than the RSA keyed intermediate that was there previously but I think we would have started to see more similar reports if that was the case.

4 Likes

I don't have a way script wise to switch back and forth between the 2 certificates. I do have the full chain pfx file separate from the standard cert the script makes. I have reloaded/reimported through the gateway interface a few different ways, nothing seems to make a difference. I even pulled the old server up and tried to see what happened with the E5 Full Chain. Same issue, something with the E5 is messing with the Mac. I'm pretty sure the certificate is transmitted via port 443 as that port is also required with the Remote Gateway

So this is what the log file from MS Report Desktop for Mac has

E|2024-07-05 11:08:04.7250 -05:00|FileLoggingWindowController.swift:243 Logging to file started!!
E|2024-07-05 11:08:11.1760 -05:00|:0 {ab684668-6174-440b-915b-e30aae2b0000} <0x70000baef000> BASIX_NETWORK_DCT(ERR): CFSocketWrapper(0x7f8a4f1bccc8): Name resolution failed: nodename nor servname provided, or not known
/Users/runner/work/1/s/externals/basix-network-s/dct/cfsocketwrapper.cpp(1090): HostClientCallBack()
E|2024-07-05 11:08:11.1760 -05:00|:0 {ab684668-6174-440b-915b-e30aae2b0000} <0x70000baef000> RDP_WAN(ERR): TcpTrans::TcpTransportOnClosed - connection attempt exception: nodename nor servname provided, or not known: No route to host
/Users/runner/work/1/s/source/stack/libtermsrv/rdp/LegacyXPlat/Transport/ClientCore/Implementation/TsTcpDctTransport.cpp(1224): TcpTransportOnClosed()
E|2024-07-05 11:08:14.5760 -05:00|:0 {ab684668-6174-440b-915b-e30aae2b0000} <0x70000be01000> BASIX_DCT(ERR): Stateful object 0x7f8a4e99b000 was destructed while in state Opened(19)
/Users/runner/work/1/s/externals/basix-network-s/dct/asynctransport.cpp(89): ~BasicStateManagement()
E|2024-07-05 11:08:14.6260 -05:00|:0 {ab684668-6174-440b-915b-e30aae2b0000} <0x70000be01000> BASIX_DCT(ERR): Stateful object 0x7f8a4fe84800 was destructed while in state Opened(19)
/Users/runner/work/1/s/externals/basix-network-s/dct/asynctransport.cpp(89): ~BasicStateManagement()
E|2024-07-05 11:08:14.6770 -05:00|:0 {ab684668-6174-440b-915b-e30aae2b0000} <0x70000be84000> BasixWebsocketEndpoint(ERR): websocket closed with std::exception: Connection reset by peer: Connection reset by peer (Error Code: 54)
Thrown in thread 0x70000be84000 at:
/Users/runner/work/1/s/externals/basix-network-s/dct/asiobasedct.h(292)
Call Stack:
Callstacks are currently disabled

Caught at:
/Users/runner/work/1/s/source/stack/libtermsrv/gateway/basix_websocket_endpoint.cpp(592): OnClosed()
E|2024-07-05 11:08:14.6780 -05:00|:0 {ab684668-6174-440b-915b-e30aae2b0000} <0x70000be84000> BasixWebsocketEndpoint(ERR): websocket was never opened, treating it as a failed websocket upgrade
/Users/runner/work/1/s/source/stack/libtermsrv/gateway/basix_websocket_endpoint.cpp(607): OnClosed()
E|2024-07-05 11:08:17.1190 -05:00|FileLoggingWindowController.swift:194 Logging to file finished!!

Interesting, most of those error messages look like they are saying it can't resolve the host dns name to an IP.

3 Likes

I Agree. The Wildcard is the same for both the R3 and E5.
R3
Subject: MyDomain.com
Subject Alternative Name:
DNS Name=*.MyDomain.com
DNS Name=MyDomain.com

E5
Subject: MyDomain.com
Subject Alternative Name:
DNS Name=*.MyDomain.com
DNS Name=MyDomain.com

I thought if maybe the *.Domain was reversed would lead me to something. Is there some Let's Encrypt "domain" on the E5 certificate that needs to be resolved that isn't? I'd say is my internet, but my windows client works fine.

Have you tested RDP server is actually up from other windows?

2 Likes

Also if the mac is on a remote network and windows is on the same network you can get very different results.

2 Likes

ok, so I have a Mac and win 10 machine at my home, Mac is getting the error, Win10 is not, same DNS info. I get the same error accessing via my iPhone using the iPhone app on my cellular network, and a co-worker with her Mac gets the same error (Comcast vs Charter). all I had to do was switch certificates from E5 to R3 to get the error or log in successfully to the RD Gateway. Not sure if it's normal to get different certificates like this, not sure what the difference is between R3 and E5. I'm too early to get a new certificate but not sure that would help.

could you ask a new certificate with rsa key (so you get r10/r11) and if that works? maybe mac client doesn't like E5's p384 curve?

2 Likes

so I forced the renew, got another E5 certificate, same issue with the error of 0x3000066.

\Certbot>certbot certonly --manual --cert-name MyDomain.com -d MyDomain.com,*.MyDomain.com --agree-tos --no-bootstrap --manual-public-ip-logging-ok --preferred-challenges dns-01 -m serverm1@MyDomain.com --server https://acme-v02.api.letsencrypt.org/directory