RDS Web Access using CNAME?

[Mike Leone]

I need some clarification. We're setting up a new RDS 2022 environment. My boss wants the RD Web Access to not use the host name when connecting to the URL, but instead to use the application name. i.e., the URL to be "elite.<FQDN>", and not "RDS010.<FQDN>".

OK, so I made a DNS alias and pointed it at the RD Web Access host. Then I issued a cert in the name of the alias, but included the hostname in the subject alternate name:

C:\Certificates>certutil -dump Elite.wrk.ads.pha.phila.gov-2025-09-18-Certificate.cer

Subject:
    CN=Elite.wrk.ads.pha.phila.gov
    OU=ISM
    O=Philadelphia Housing Authority
    L=Philadelphia
    S=PA
    C=US

    2.5.29.17: Flags = 0, Length = 35
    Subject Alternative Name
        DNS Name=DC1RDS010.wrk.ads.pha.phila.gov
        DNS Name=Elite
        DNS Name=DC1RDS010

I then went into Server Manager, changed the deployment to use that cert for all 3 - Connection Broker - Enable Single Sign on, Connection Broker - Publishing, and Web Access. All are Trusted, all show status OK.

I then went to IIS, changed the bindings to use that new cert. I added the DNS alias as the hostname in the bindings screen.

Yet if I go to that URL - https://elite.wrk.ads.pha.phila.gov/RDWeb/Pages/en-US/Default.aspx - it comes back with an error that the site is not valid. COMMON NAME INVALID.

This server couldn't prove that it's elite.wrk.ads.pha.phila.gov; its security certificate is from DC1RDS010.wrk.ads.pha.phila.gov. This may be caused by a misconfiguration or an attacker intercepting your connection.

In IIS, I still have the old cert, in the hostname (DC1RDS010), but it's not bound to anything.

What did I do wrong? Should the cert have the common name of the host, with the DNS alias as a SAN? Did I do it backwards?

--

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

[James Iversen]

Spn on server AD object. Add hostname given. 

Sent from my iPhone

On Sep 18, 2025, at 9:26 AM, Mike Leone <tur...@mike-leone.com> wrote:



I need some clarification. We're setting up a new RDS 2022 environment. My boss wants the RD Web Access to not use the host name when connecting to the URL, but instead to use the application name. i.e., the URL to be "elite.<FQDN>", and not "RDS010.<FQDN>".

OK, so I made a DNS alias and pointed it at the RD Web Access host. Then I issued a cert in the name of the alias, but included the hostname in the subject alternate name:

C:\Certificates>certutil -dump Elite.wrk.ads.pha.phila.gov-2025-09-18-Certificate.cer

Subject:
    CN=Elite.wrk.ads.pha.phila.gov
    OU=ISM
    O=Philadelphia Housing Authority
    L=Philadelphia
    S=PA
    C=US

    2.5.29.17: Flags = 0, Length = 35
    Subject Alternative Name
        DNS Name=DC1RDS010.wrk.ads.pha.phila.gov
        DNS Name=Elite
        DNS Name=DC1RDS010

I then went into Server Manager, changed the deployment to use that cert for all 3 - Connection Broker - Enable Single Sign on, Connection Broker - Publishing, and Web Access. All are Trusted, all show status OK.

I then went to IIS, changed the bindings to use that new cert. I added the DNS alias as the hostname in the bindings screen.

<image.png>

<image.png>

Yet if I go to that URL - https://elite.wrk.ads.pha.phila.gov/RDWeb/Pages/en-US/Default.aspx - it comes back with an error that the site is not valid. COMMON NAME INVALID.

This server couldn't prove that it's elite.wrk.ads.pha.phila.gov; its security certificate is from DC1RDS010.wrk.ads.pha.phila.gov. This may be caused by a misconfiguration or an attacker intercepting your connection.

In IIS, I still have the old cert, in the hostname (DC1RDS010), but it's not bound to anything.

What did I do wrong? Should the cert have the common name of the host, with the DNS alias as a SAN? Did I do it backwards?

--

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BhBjVQgX24oM-%2BMUPg%2BHJA7eu8wcLonVkoFFf4T-Ddu8g%40mail.gmail.com.

[Mike Leone]

On Thu, Sep 18, 2025 at 10:47 AM James Iversen <jeiv...@gmail.com> wrote:

Spn on server AD object. Add hostname given. 

Well, I re-issued the cert with the command name as the hostname, and the ALIAS as SANs. And the short form of the alias - https://elite - works fine, shows valid cert. Using  the FQDN of the alias - https://elite.wrk.ads.pha.phila.gov - does not, shows invalid cert.

I am not comfortable with making SPN changes in AD. Especially when the response shouldn't have anything to do with AD - what if the webserver was not running a domain member? Like if it was running on my DMZ? There should still be a way to get it to respond to such a CNAME, adn have nothing to do with AD changes.

This is OK for now, I think, but I'll keep tinkering with it.

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/43F8FD4E-8869-490E-96A5-4399E2C84558%40gmail.com.

[James Iversen]

The CA is AD integrated? Glad things work for now. Have fun tinkering. 😀

Sent from my iPhone

On Sep 18, 2025, at 10:55 AM, Mike Leone <tur...@mike-leone.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BiFSniFwTJswpjfv17k6yW-wMjNtOWfPY22gBbg%2B3ZzCw%40mail.gmail.com.

[Mike Leone]

On Thu, Sep 18, 2025 at 11:18 AM James Iversen <jeiv...@gmail.com> wrote:

The CA is AD integrated?

It is!

 

Glad things work for now. Have fun tinkering. 😀

Sent from my iPhone

Yeah, I think this is good enough, for now. As far as I've been told, all the users click on a link on our internal portal anyway. Nobody actually types in the URL. Maybe some have it saved as a favorite, but I doubt even that ...