Mac RDP not able to connect to E5 wildcard

I have not been following along but I believe the suggestion was to get an RSA cert. Adding these to your Certbot command should do that

--key-type RSA --rsa-key-size 2048

Normally the key size is not required but I recall some versions of Certbot needed that when switching from ECDSA to RSA. It doesn't hurt in any case since that is the default size for RSA

From the manual

--rsa-key-size N Size of the RSA key. (default: 2048)
--key-type {rsa,ecdsa}
Type of generated private key. Only ONE per invocation can be provided at this time. (default: ecdsa)

4 Likes

What did you expect with forcing the same thing?

2 Likes

Adding the
--key-type RSA --rsa-key-size 2048
fixed the issue.

2 Likes

what's your Mac RDP client, can you give link to it so I can write a bug report about not supporting p-384?

4 Likes

Interesting though, the cert itself would have been EC if just using the same certbot, so it is the EC intermediate that's being problematic for the client.

I think you are using the official Microsoft RDP client ‎Microsoft Remote Desktop on the Mac App Store

[Edit: I'll see if I can find someone who can help get the client fixed]

2 Likes

In my own testing just now using macOS 14.4 with the latest Microsoft Remote Desktop client I can confirm that I am able to use E5 and E6 intermediates (leaf cert using ECDSA 384) with no issues.

I am using Certify The Web on Server 2022 to generate and apply the certificate (in my case using the Deploy to Terminal Services Listener task as I'm not running a full RDP gateway).

There may still be some combination that has a bug but I'll wait for others to reproduce the issue.

3 Likes

Hmm maybe leaf and intermediate using differnet curve cause problem than?

4 Likes

Maybe. Or, maybe we have not interpreted their post #1 correctly. We have had to make guesses as we don't have the actual domain name to look at the certs.

When they said "refresh" the cert I thought they meant they setup a new Certbot system or at least a new cert profile. I didn't read it as a strict "certbot renew".

If that's true it is possible the R3 in the first post was with an RSA leaf. And the new "refreshed" cert got the ECDSA leaf with an ECDSA intermediate and this failed.

Reissuing the cert with --key-type RSA then got an RSA leaf and an RSA intermediate which worked.

So, it seems possible to me that their client could just be having a problem with ECDSA.

It's possible I've misunderstood something in this history. It is difficult to parse through complex symptoms without the actual domain names.

4 Likes

My RDP Client is Microsoft Remote Desktop 10.9.8. The iPhone version is 10.5.9. This was a wildcard cert (*.MyDomain.com), so not sure if that is a difference on how it generates, but again, with the RSA switch, certbot generated an R11 certificate.

so I wrote an Powershell script to run certbot (2.2.0) and openssl (3.2.0)

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 CertAdmin@MyDomain.com --server https://acme-v02.api.letsencrypt.org/directory --key-type RSA --rsa-key-size 2048
and then run openssl to create a pkx file
openssl pkcs12 -inkey ($LivePath + "privkey.pem") -in ($LivePath + "fullcert.pem") -passout ("pass:" + $CertPassword) -export -out ($archivepath + "Privkey" + $NewNum + ".pfx")
For some reason this generated the R3 wildcard certificate without the RSA switch, not sure why it switched to E5. PM me if you want to look at the cert. Now the website is showing R11.