You are viewing limited content. For full access, please sign in.

Question

Question

FormsMultiServerConfigurationUtility.exe - SSL Renewal Procedure Question

Forms
Updated December 9, 2024
asked on December 4, 2024 • Show version history

We are renewing our SSL certs for the year and after a mid-year upgrade the procedure from last year to now has changed.  

 

Sections inside the web.config file on our DMZ Forms server no longer exist and the EndPointUtility.exe program inside the Forms/Bin folder is no longer there.

 

What is new is a program called FormsMultiServerConfigurationUtility.exe - unfortunatley our VAR has not seen this program before and somehow our Support Contract with Laserfiche expired...27 days before our license does.  So we have no LF mothership support, only with our VAR.

 

Does anyone have any experience with this program in setting a 2025-expiration SSL cert for a DMZ / Internal forms environment?

It looks straight forward, but 2 years ago our SSL renewal went sideways and we were down for a full business week.

 

My intial thoughts are select the new 2024-2025 SSL cert, fill in the FQDN of our internal forms server and if possible select the first option for proxy lookup (we can't create lookup rules if using DMZ server currently)

Thank you in advance.

Utility screenshots:

 

0 0

Answer

SELECTED ANSWER
replied on December 6, 2024

It does provide insight. If you had to add <identity> tags, you're using native/default WinAuth for service-to-service communication, not certificate auth, and do not need to update anything in the Forms "*.config" files during certificate rotations.

0 0

Replies

replied on December 4, 2024 • Show version history

Hi Brian,

If you are asking about a certificate renewal for end users connecting to the Forms IIS application over https/443, simply import the new certificate and update the https/443 site binding in IIS to use it: 

How to Set Up SSL on IIS 7 or later | Microsoft Learn (screenshots are from an older version of IIS but the steps are exactly the same)

The FormsMultiServerConfigurationUtility.exe certificate configuration is about configuring WCF Transport Security with Certificate Authentication between the Forms IIS application(s) and the Forms Routing Service. 

I strongly suspect you did not have this previously configured as it's a relatively new config option. You would thus not be at risk of issues from certificate expiration for that communication path, on account of WCF transport security with cert auth not being enabled. You would know if you had this set up - before the FormsMultiServerConfigurationUtility existed to semi-automate its setup, the only way was to painstakingly modify the configuration files by hand following a procedure that is not publicly documented.

To be explicit: Running the FormsMultiServerConfigurationUtility ("Save") will break your current configuration if you set the TransportSecurityMode to "None" per the general instructions in the Forms DMZ setup whitepaper. In order to promote more secure defaults, the FormsMultiServerConfigurationUtility does not have an option for TransportSecurityMode = "None" between the DMZ Forms IIS instance and the internal Forms Routing Service.

If the DMZ Forms server is domain joined to the same (or a trusted) Active Directory domain as the internal Primary Forms Server, you can run the FormsMultiServerConfigurationUtility on both servers and select the "Windows Authentication" credential type to easily secure (authenticate and encrypt) traffic between those servers without needing to deal with certificates yourself (they're still involved but automatically managed by AD).

0 0
View 1 previous reply
replied on December 6, 2024 • Show version history

Thank you Samuel.

 

You mentioned "You would know if you had this set up - before the FormsMultiServerConfigurationUtility existed to semi-automate its setup, the only way was to painstakingly modify the configuration files by hand following a procedure that is not publicly documented."

Last year when renewing certs, we had to edit the Web.Config file under Laserfiche Forms / Config and add in endpoint addresses for our lfds server as well as <identity> tags that point to our domain. 
 

I would have to confirm, but I believe our external / DMZ forms server is on a trusted domain that has the ability to communicate with our internal forms server.  

Not sure if this provides any further insight.  All my "tests" using the FormsMultiServerConfigurationUtility.exe have failed.  Both with certs and with windows authentication - however we use wildcard certs and from what I understand, there may be an issues with that and this utility. 

0 0
SELECTED ANSWER
replied on December 6, 2024

It does provide insight. If you had to add <identity> tags, you're using native/default WinAuth for service-to-service communication, not certificate auth, and do not need to update anything in the Forms "*.config" files during certificate rotations.

0 0
replied on December 9, 2024

The certs were updated today and we did not use the FormsMultiServerConfigurationUtility.exe 

 

However we did have to alter the web.config files on our DMZ server as well as our Webclient server as it was referencing a hard-coded certificate thumbprint.  Once those were updated and the endpoint utility on App-LFDS was updated we deleted the soon-to-be expiring certs (just to make sure they weren't being used somewhere we hadn't discovered) and Forms/Webclient continued to function.

Thank you for the help.

1 0
replied on December 9, 2024 • Show version history

That suggests you had the Configuring the Security Token Service On A Separate Machine for Single Sign-on setup with the "Alternate Service" (aka certificate auth mode) for the various web app services to authenticate to LFDS.

If the Forms DMZ and Web Client servers are on a domain trusted by the LFDS server, using the LFDS Alternate Service is not necessary and adds operational complexity from needing to rotate the client certificates. 

If the separate STS/Forms/WebClient is domain joined as described, they should ensure that "Use TLS" is enabled for STS and that LFDS has a valid cert bound to port 5049 (XmlEndpointUtility) to encrypt the communication. The STS/Forms/WebClient->LFDS authentication part happens automagically with service-to-service WinAuth. This is simpler and has lower operational complexity than the Alt Service config because there aren't any client certificates involved, only the server certificate for LFDS on 5049, which means certificate rotations (for this service-to-service path) only happen with one cert in one place. 

Same idea as the WinAuth vs Cert Auth option in the FormsMultiServerConfigurationUtility. The Cert Auth is a backup option for scenarios where the prereqs (domain join status for both machines) for WinAuth (the default) aren't met.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...