- This topic has 22 replies, 4 voices, and was last updated 3 years, 8 months ago by
.
-
Posts
-
Hi all
First of all, newbie here.
I’ve setup RDS on Server 2019 and I can login via website [dnsname.domain.local] (I’ve redirected it to “rdweb”).
I’ve bought a Wyse 3040 with ThinOS (WTOS?) Build 8.6_013.
I’ve set following settings:
Brokertype: Microsoft
Broker Server: dnsname.domain.localWhen using a login that works via web browser, on Wyse I get a “Certificate common name is bad”.
I’ve tried putting two certificates on an USB but cannot import from “System Tools” > “Certificates”. It just says “No USB device found”.
Can someone steer me in the right direction? 🙂
Thanks.Will try that right away. I thought new thin clients would be more modern? 🙂
I’ll return whether it worked or not.
I must use the USB2.0 port and import went well. I imported the self-signed certificate first and tried it. Then the computer-certificate and tried again.
Still gets the “Certificate common name is bad” error 🙁
Thanks for getting the USB working.Do you have any steps I can try fixing the error as well? 🙂
Sounds like the common name in the certificate doesn’t match the real name
CG
Yeah, that’s what I’ve read. But don’t know what that actually mean then.
I’ve just created it and then exported it. So what “real name”? 😀
And of course, thanks for your time answering my questions!
Just tried creating a new certificate following this video [https://youtu.be/oIos0TbZfjY?t=510]
Used it on the server as mentioned in video. Imported in on the Wyse (several attempts is needed before USB is recognized) but still the same error 🙁
I having some days off for now (back tuesday) and will check in here. Hopefully someone can help 🙂
Maybe the problem is elsewhere…You cannot use a pfx cert for ThinOS at that point.
Open a browser and connect to your RDWeb server. In the URL line you should see a successful SSL connect (small key lock).
Click it and download the certificate from there. Should be a CER file based DER encryption.
Import that to ThinOS and try again.CG
Now I know something is setup wrong then.
Because in the browser I get this error: “DLG_FLAGS_SEC_CERT_CN_INVALID”
So the certificate isn’t working there either. I haven’t installed it on my PC, is that needed for this?I tried installing the .pfx but website still gives error
To have something to compare with, try to open the certificate of this site.
When you look at the address in your browser, it is: https://technicalhelp.de
Open up the certificate, go to the details page and find the Subject line.
It says: CN = http://www.technicalhelp.deAlso take a look at the Subject Alternate Name, there you have:
DNS Name=www.technicalhelp.de
DNS Name=technicalhelp.deNow compare this to your own certificate. What you use as address for your RDWeb server must match the Subject CN in your certificate for ThinOS to accept that the Certificate is OK for your RDWeb server. Some browsers also check the Subject Alternate Names. and at least one DNS Name entry must match as well.
If these two things do not match your Servers address in the Certificate you have installed, the connections will not work correctly. Other things in the Certificate, like issue and expire times must obviously also be OK.
If everything looks OK in a Web Browser when you inspect the Certificate, download it from there (Copy to File) and export in DER encoded format as a .CER file and use that as ConfGen instructed.
Hope it helps.
/Frank
I’ll look into it.
Thanks for the detailed explanation 🙂
Tak for hjælpen 🙂
I’ve tried making a new certificate but seems to export to .pfx only.
I “Create new certificate” under the RDS management on Server 2019
Subject name before was CN=RDS
Now it’s CN=rds.domain.local and sounds more right.The browser however still gives “Fejlkode: DLG_FLAGS_SEC_CERT_CN_INVALID”
And I only have the .pfx certificate
Exported from “Trusted Root Certification Auth.” for a .cer file and installed that in four ways on my own PC, still with no luck. 🙁Chrome or Firefox?
Chrome validates the SAN entries in the Certificate, I am not sure about Firefox.
Can you ignore the error and continue to the RDWeb interface in the Browser?Check how the new Certificate looks from there, and export it from the Browser, not from the Certificates console. The browser should have the option you need for .CER.
I don’t think the self-signed certificates created by RDS Management adds SANs to the certificate. I use the Microsoft Certificate Services, as it can automatically deploy and maintain RDS certificates to the session hosts. Even with that, it is a bit tricky to get SAN entries included for the RDWeb Certificate.
But if you only intend to connect to RDWeb using ThinOS, currently the SAN entry is not needed.
/Frank
IE11 and just tried it on Chrome
Chrome gives this:
NET::ERR_CERT_COMMON_NAME_INVALID
Subject: servername.domain.localIssuer: servername.domain.local
Expires on: 12. jun. 2020
Current date: 12. jun. 2019
I can easily go to the site and login and get the RDP desktop. (I’ve forwarded it to /rdweb)
Chrome says the certificate is invalid.
For now it’s only a test with thin clients, but in the future people should connect from outside.
OK, you could be causing yourself headaches trying to get everything working with self-signed certificates. If you will have people connecting from Outside (I assume Internet), you probably also need the RDS Gateway and not just Broker and RDWeb.
If you have already decided on the public name, maybe it is time to order a “Real” publicly signed certificate from a provider already trusted by ThinOS.
It will cost some money, but you may save a lot of time.Be aware that you will probably not be able to order a Publicly signed certificate with .local domain names as SAN DNS entries, so Internal clients will need to be able to resolve the Public DNS name and get the Internal IP (Split DNS).
This guide helped me a lot when starting with this: https://www.rdsgurus.com/windows-2012-r2-how-to-create-a-mostly-seamless-logon-experience-for-your-remote-desktop-services-environment/
It is for RDS 2012R2, but most things probably still apply to 2019.
/Frank
- You must be logged in to reply to this topic.