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)
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.
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.
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.
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.
Hard tell, if I check the provided domain (which is there if you look hard enough!) on the standard RDP port there is no cert, so we're not working with all the info.
OS version is Server 2022 so should have a good set of cipher suites unless it was upgraded in-place from an old version.
It worked for me with E5 and E6. The only way to prove it's not working is to spin up a new demo server for others to try, until then it appears that this problem is isolated to your own environment or workflow.
There could still be a problem, and there clearly is for you, but we haven't yet proven that it's a general problem that would affect anyone else (e.g. a software bug).
I'm afraid I'm not versed enough to know what the difference is between RSA vs ECDSA that I might be able to troubleshoot. It's either this option which was working, stopped when it switched to E5, and now is working again with R11. While Certify the Web is inexpensive, I would fall back to the method we were using for the commercial certificates for the 4 non-wildcard domains. I will probably cross the bridge when CertBot no longer is able to obtain a viable certificate.
Yes, we have run into the same issue just recently, affecting two different companies across the globe, the only thing they have in common it's RDGW server with LE certificate.
So I made a couple of tests and found this:
Mac RDP client (native MS app from AppStore) throwing an error:
Connection reset by peer (Error Code: 54)
OSSL_CERT_VALIDATE(NORM): OnCertVerificationCallback called, cert error="unable to get local issuer certificate" (20)
But if I stop the RDGW itself (just this service, not the whole IIS) the client is attempting (!) to connect without this error, obviously failing on the next step with different error. So handshake client->IIS is happened ok, while handshake client->RDGW isn't.
Of course IIS is configured with absolutely same certificate as RDGW.
Just FYI — seems like it's not the first and not even second issue with this client app and the way how it handling RDGW connections.
@3apa3a-b-ta3e cool, so why does it work for me and not for you. The error suggests the CA certificate store in macOS is not update to date. Browser TLS may be more resilient than RDP client as they will likely be completely different TLS software stacks and the browser may even have it's own dedicated (and up to date) trust store.
Is it possible the RDP client isn't reading the Subject Alternative Name properly. I'm not sure if its advisable to reverse the MyDomain.com, *.MyDomain.com so that the wildcard is first in the list (or if the preference is to have it reversed)