Question

Internal CA SSL Certificates When Setting Up Two Forms Servers with Two STS Instances

Administration Directory Server

Updated January 9, 2020

asked on October 3, 2019

We have done quite a few DMZ setups for clients and we always seem to have the most trouble when they are using an internal certificate authority (CA). The issue comes when setting up an STS in the DMZ and on the LFDS server. Since the DMZ server is not on the domain, it does not trust the internal CA. So when the STS in the DMZ is configured to use Certificate Authentication, it cannot validate the certificate configured on the internal STS. To get around this we have been adding some code to ignore the trust chain of the certificate, but I know that is not recommended.

So my question is, what ways are available for the STS on the DMZ server to trust the internal STS's certificate since it cannot talk to the internal CA?

1 0

Replies

replied on October 3, 2019

Have you tried adding certificates directly to the machine's trusted roots? Either the SSL cert you want to use or the internal cert that was used to issue it.

0 0

View 1 previous reply

replied on October 3, 2019

I haven't tried this particular scenario, but I would expect it to work. It's the same way your browser can trust SSL certs issued by Verisign without communicating directly with Verisign - you have a copy of the cert and can validate that it was used to issue the site's cert.

1 0

replied on October 3, 2019

Is this something that Laserfiche can test and let us know the proper steps to do this?

0 0

replied on October 4, 2019

Certificate validation is processed entirely by Windows, so it is outside of scope of Laserfiche testing.

That said, certificate processing happens solely on the machine against the known root certificate authorities. Windows doesn't go out to Verisign to validate a certificate. It will check it against its local Verisign certificate authority if a valid one exists. If it doesn't, then validation will fail. That's exactly what happens for your internal certificate. It's not that the DMZ machine can't get to your internal authority, there is no local authority to vouch for the certificate. By importing the certificate into the trusted root store, you are telling the DMZ machine that anything that has a trust chain leading to this authority is a valid certificate.

On that same vein, while you can use this method for the certificate used to secure the STS' communication with LFDS, you won't be able to use it on the website that hosts the login screen for STS (or any other user-facing web application like Web Access or Forms on a DMZ server). In the website's case, the certificate has to be valid on the browser that will be accessing the site. The browser will check the certificate stores available on the machien it's running on, not on the server. That could, technically, be any machine in the world, so since you can't push your internally signed certificate to those machines, you'll need a "real" certificate from an externally recognized authority.

2 0

replied on October 3, 2019

I can't comment on the implications of using this "temporary" approach in a production environment, but I use this method when testing DMZ setups.

0 0

replied on January 9, 2020

Blake -

My understanding when using an Internal Certificate Authority on a site exposed externally, the site will only be valid to anyone on the domain. For sites published on servers in the DMZ, you will need to purchase a third party certificate.

0 0

replied on January 9, 2020

Cameron,

That is true for the certificate used for the end user facing part of the software, but not for the certificates that are used for the communication between the STS's.

0 0

You are not allowed to follow up in this post.

Question

Question

Internal CA SSL Certificates When Setting Up Two Forms Servers with Two STS Instances

Replies

Sign in to reply to this post.