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



How to properly, step-by-step configure Laserfiche with a SSL Cert?

asked on May 24, 2019 Show version history


I have a situation where my server is running on a non ssl cert. This is causing me to not be able to use Forms via mobile app. Which means we are paying for a service I cannot get to work for the end users.

My goal is to configure my product suite so that Workflow, Forms, Repository, Mobile and any other component of Laserfiche functions exactly as it is right now, but only via HTTPS.

I have had a good 6 hour crack at this after work yesterday and feel like I nearly got it working.

When I came in today I saw people are receiving errors left and right. Such as unauthorized login screens before even being prompted for login details.

Text files are attached with every error Event viewer has under Forms -> Operational.

Why would it tell me my notification server is down?

The scariest part was when I tried logging into Formsconfig/LFDS/STS, the username and password was not accepted. Which I am certain are the correct credentials, the credentials were used on the previous config, don't know if this changes when using a new cert?

What I did was, configure the xmlutility to use the new host.domain, and pass the credentials, I tried typing it in every combination I can come up with.

In the fully qualified domain name I had my certificate name (The "Issued To:" in IIS).

I had my SSL cert selected.

My primary security token was my server name.

In the approved security token services it was https://"Issued  To in IIS":443/


I also configured the STSEndPointUtility. Currently the fully qualified domain name is the server IP, which works. I had it configured on the "Issued To:" in IIS. 

The "Service user's principal name" was the adminuser@"Issued To:" in IIS. I tried selecting alternate security token and also configuring while deselecting.

At this point I did not know what I was doing wrong or right anymore. I checked user access rights to all the local files, and thought, how can this be the cause since the other cert works perfectly fine with the current user rights? And I ruled this out.

I tried configuring the "hosts" document in System32:

I merely added the server IP followed by the domain name and saved. It did literally nothing.

I could browse to all the bindings perfectly fine. I had more than one for my default site, so I deleted all but the new shiny SSL one. It did nothing.

I could still not login to formsconfig, LFDS or LFDSSTS. I could get into the Repository and Forms though, since it does not require an admin login.

Why would this change affect my admin credentials? What did I do wrong? Can anyone assist me please.


1 0


replied on May 24, 2019 Show version history

It sounds like you are running into a mix of dns and certificate problems.  I would suggest going back to http everywhere (what I think you mean by "running on a non ssl cert"?) and first switch to using FQDNs.  You'll need to register in dns the addresses that are failing to resolve.  This switch is probably also the cause for the "unauthorized login screens" you are seeing, since Windows authentication works differently with FQDN.  You might need to add the sites to your trusted sites.  Is there a reason you are resorting to editing the hosts file instead of using dns?

Once you're working with FQDN it should not be too difficult to load certificates issued to those names into those servers, and update the applications to use HTTPS.  What are you using as your CA?  Remember that not only does the cert have to match the host name, but the cert has to be trusted by the client.

1 0
replied on May 27, 2019

Yes when I refer to non ssl I do mean http, apologies I am fairly new to the server level configuration of Laserfiche as my main focus has been development for the past 2 years.

When you say first switch to using FQDNs, do you mean first tell Formsconfig, etc to use the new address, and then configure everything in IIS?

My address is definitely registered and bought from GoDaddy, is that what you mean by register?

The reason for me editing the hosts file is simply because I do not have a decent understanding of how to configure this properly. I did it as a step to see if I can get this whole thing working. I am not 100% sure what that file's purpose is to be honest. - Didn't do much research, just want to get my services working.

Once I'm working with FQDN, so you mean to tell me I must first configure everything to use the certificates FQDN, and then go to IIS?

Using GoDaddy.

Ok so Craig posted a guide here, I am going to follow it and see if it helps.

Thanks for pointing out some stuff. I'll keep everything you said in mind.


0 0
replied on May 28, 2019

Yes, first get things working when the servers refer to each other with FQDN.  This is a necessary step because those are the names that will appear in the certificates, right?  After you get the servers talking to each other with the new names, then you can start loading certificates and switching protocols.

The hostname in the error log is "".  `C:\>nslookup` returns "non-existent domain", though you can register it via GoDaddy for $9.99.  Registration is only the first step, then you have to set up dns.

0 0
replied on May 29, 2019

I posted the wrong error, I did type the name in wrong at some point during testing.

The correct one is - My bad.

Okay so I am taking a new approach to this and installing LF from scratch on a dev machine. I am basically trying to replicate the issue and fix it there since I cannot make random changes on the live box and cannot keep jumping between configurations.

0 0
replied on May 29, 2019

Ok, I do see a dns entry for that server.  It's showing an private internal IP address (192.168.x.x).  If this server is for internal use only, you probably don't want it to have a public dns entry.  If it does need to be externally reachable, you will need an external IP address.

0 0
replied on May 29, 2019

Our internal users access LF from outside the office/network. We do want to go over to public access as we have ideas in place for future processes.

I am receiving support from our VAR today and I hope it will solve my problem.

0 0
replied on May 30, 2019

You were right initially..

The configuration I was trying was completely wrong..

I was typing in stuff that doesn't belong there.

It was so straight forward when the guy did it for me.

Thanks for the help.

0 0


replied on May 24, 2019

This guide should help you step-by-step in setting up SSL.


1 0
replied on May 27, 2019

I will try this guide in off-peak hours.

I'll get back to you as soon as I had a chance to try it out.

Thanks Craig.

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

Sign in to reply to this post.