DVLS / RDM: The remote certificate is invalid according to the validation procedure.

Hello,

Do you get the same behaviour with the latest RDM beta 2022.1.10?
https://devolutions.net/remote-desktop-manager/home/download#Beta

Best regards,

Hi Erica

With 2022.1.10 I can't conntect to DVLS - i get the following errors:








I do not want to share the full details in public - if you need to know more information, just let me know. I can send you that information by mail.

Regards Felix

Hello,

Thank you for the information.

Could you please verify if the issuer and the authority are identical? As this is case sensitive, it is preferable to set everything with lower case letters.

Let me know if that helps.

Best regards,

Hi Erica

Cert (Subject / Subject Alternative Name) should not be case sensitive.
However, i've created a new cert (all lowercase) - still the same error.

Devolutions.Server.ApiWrapper.Exceptions.OAuthAuthenticationException: Issuer name does not match authority: https://sclouddvls****.*****.net/dvls
   at Devolutions.RemoteDesktopManager.Business.DataSources.DVLSOauthConnector.Login(String refreshToken, String loginHint, Boolean isWindowsAuth)

Why do you explicit ask for "Issuer"?
"Issuer" is not the FQDN / Name of the Devolutions Server -- it's the Name of the Issuing Certificate Authority.
Do you mean "Issued to" (Subject / Subject Alternative Name)? Then yes, this is the FQDN / URL of the Devolutions-Server.

Mostly by self-signed Certs are the Issuer and Subject the same (because it's issued by itself) However, this is not the case by (public) trusted Certs!

Issuer: Name of the Issuing Certificate Authority (for example: MyCorp-CA)
Subject / Issued to: FQDN /URL of the DVLS (for exmaple: dvls.mycorp.net)
Subject Alternative Name: FQDN /URL of the DVLS (for exmaple: dvls.mycorp.net)


I do not want to share the full details in public - if you need to know more information, just let me know. I can send you that information by mail.



New Cert, all lower-case











Regards Felix

Hi Felix,

Thank you for your feedback.

Let me check with the engineering team and I will get back to you.

Best regards,

Hi Felix,

Could you please send us the certificates information without the private key and the DVLS Access URI value you have set?

Our team will have a look on your configuration.

Best regards,

Hi Erica

The DVLS Access URI was not lower-case - i've changed that and now it works ;-)

Thank you for your help!
Regards Felix

Hi Felix,

Thank you for your feedback and glad that with the Access URI set in lowercase the issue is now solved.

Best regards,

Hi Felix,

I have one last question.

What part of the Access URI in uppercase letters? Was it the host name, the DVLS application path (/DVLS) or the whole Access URI?

Best regards,

Hi Erica

Part of the Hostname was in Uppercase, Domain and application path was lowercase.
For Example: SCloudDVLSxx.domain.net/dvls

Regards Felix

Hi Felix,

Thank you for the information.

Another question.

Did you upgrade or create your DVLS instance with the DVLS Console or the CLI?

Best regards,

Hi Erica

I've created the DVLS instance with the DVLS Console (latest stable version).
Then I've upgraded to the beta DVLS Console and upgraded the DVLS instance to the beta (all within DVLS Console).

The PFX (Cert) created I in advanced of the DVLS setup and choose it during the setup. (This was the Cert with Upercase in the Subject).
The new Cert (all lowercase) have I assigned in the IIS, bindings for the Website with the DVLS Application.

Regards Felix

Hi Erica

[16.02.2022 19:03:29 - 2022.1.11.0 - 64-bit] Error Silent: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

Unforunately i'm facing the same error again with the latest Version
RDM: 2022.1.11.0
DVLS: 2022.1.7.0
DB: 1.751

I've send the stack-trace to your Support. If you need more information, just let me know.

Regards
Felix

Hi Felix,

Thank you for your feedback.

Let me check again with the engineering team about your issue and I will get back to you.

Thank you for your patience.

Best regards,

Hi Felix,

Could you please send us the certificates information without the private key and the DVLS Access URI value you have set? If you can include the Root CA, that would be great. Please send this to service@devolutions.net.

Our team will investigate this and I will keep you posted.

Best regards,

Hi Erica

I've updated to the latest Version:
DVLS: 2022.1.9.0
RDM: 2022.1.12.0

Right now, I can't reproduce the Error. May something has changed in this Version regarding the Cert check?

I've sent the requested information to you by mail.

Best regards
Felix

Hi Felix,

Thank you for your feedback.

I'm glad to read that your issue no longer exist. I will check with the engineering team if they can lead me to an explanation.

Thank you for your patience.

Best regards,

Just to let know that this behaviour is still present today. I was struggling to connect to the server and this post here helped me see that I did not put the server name all in lowercase in the URI field.

Hello Dominic,

What DVLS version are you using?

The Access URI property is case-sensitive. We must use the same case format when we want to reach the DVLS instance from RDM, Launcher, Workspace, or the browser.

Let us know if you have any more questions.

Best regards,