Typically under /Applications and Services Logs/Laserfiche/WebClient/Server/Operational. We don't know what the error is yet, so it's too early to say how to fix it.

Hi Brian,

This what I get in event viewer.

"

One or more errors occurred.
Operation: /laserfiche/DocumentService.ashx/GetMetisToken
  Message: Exception encountered, stack trace:
  WebAccessServices.HttpHandlers.DocumentService.GetMetisToken
  System.RuntimeMethodHandle.InvokeMethod
  System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal
  System.Delegate.DynamicInvokeImpl
  WebAccessServices.HttpHandlers.BaseWAIHttpHandler.InvokeFunction
  WebAccessServices.HttpHandlers.BaseWAIHttpHandler.ProcessRequestInternal
Exception details:
  Message: One or more errors occurred.
  Stack trace:    at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at WebAccessServices.HttpHandlers.DocumentService.GetMetisToken(String repoName, Int32 documentId, String version)
  Message: An error occurred while sending the request.
  Stack trace:    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at WebAccessServices.HttpHandlers.DocumentService.<SendToMetis>d__93.MoveNext()
  Message: The request was aborted: Could not create SSL/TLS secure channel.
  Stack trace:    at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
   at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)

  Repository: METAREPO
  Session: xvqx3tmn"

Thanks

"Could not create SSL/TLS secure channel" suggests that you are not using a proper certificate for your https site. Did you have to accept an invalid certificate warning in your browser? That will allow the browser to connect, but back-end services don't typically have a similar mechanism. If this is for a production system, you should have a proper certificate. If it's for a stand-alone demo system, you can place the certificate in your machine's trusted certificate store, which will allow it to be used in the document rendering process.

Hi Brian,

This for a stand-alone demo system. How can I place the certificate in the trusted certificate store if I only created a self-certificate? If I turned off the HTTPS and I only use the HTTP it is possible to see the Microsoft file in Laserfiche viewer?

Thanks

You can add it like this: https://aboutssl.org/installing-self-signed-ca-certificate-in-window/. There are KB articles about what you would need to change to get http to work, but it's more work than trusting the certificate.

Hi Brian,

Thank you for this link. I will do it first, If I encounter a problem I will till you here.

Thanks

Hi Brian,

After I did what is in the link procedure, I still cannot view the Microsoft File on Laserfiche document viewer.

Hoping for another solution.

Thanks

When you go to the site in the browser, does it warn you about the certificate? Until that message goes away, the connections won't be established and the image won't be displayed.

You must have a valid certificate authority to use this feature?

A valid certificate, yes. Back-end services need to communicate over https which requires valid certificates.

Ok, we communicated with IT. To be specific, https only requires a certificate, not an authority. This feature requires an authority.

A certificate with an authority includes encryption and prevents DNS duping by verifying the host with each connection, while a certificate without an authority only provides encryption which prevents sniffing of traffic.

But sniffing traffic and duping to fish data are very different malicious activities.

Since both security concerns are serious, we always recommending both a certificate and an authority though. Some departments are less concerned with the authority side however.

Errr...that does not sound right. Certificates are issued by a certificate authority. It can be local to your domain for certificates that are only used within the domain or it can be an external one for certificates that also need to be validated externally. When a certificate is presented, the calling party will attempt to validate it by following up the certification path to determine if it trusts the authorities listed there.

Some connections offer the option to ignore invalid certificates, but unless that's specified, verification with the issuing authority will always happen.

Suffice it to say, always use trusted certificates.

Yea so if it doesn't trust their authority, then it doesn't work. Because these guys are creating a self-signed certificate and that is all, so they can encrypt the data.

We are communicating that softwarte vendors are really cracking down on having an authority, obviously Google and Microsoft are being hardcore about it as well. It is just that we can't stop people from not doing it entirely, and we certainly don't want to remove the certificate exposing credentials on network traffic.

One important point of this thread is that there is a distinction between "trusted" and "issued by a certificate authority". You can refer to the post earlier in the thread where I provided a link to instructions on how to trust self-signed certificates.

That said, with Active Directory having built-in Certificate Services, there are really only very few scenarios where using a self-signed certificate is the right way to go. Just earlier this week I installed an https certificate on a new laptop and it took less than 5 minutes from start to finish, and this certificate is trusted by every machine on our corporate network.

I am familair with that approach as well, the problem is when a self signed cert is created just to get the encryption enabled and they never follow through with trusting it on the domain to protect against dns duping.

A dns dupe of a service seems a bit far fetched though.