Is there any way to see which of these is the reason?

I know the certificate bound to the port I am using, 443, is not expired.

I tried connecting using the DNS entry that matches the friendly name on the certificate

A bit confused regarding TLS configurations, I am using SSL, where TLS is a different protocol than SSL. TLS is the new standard but Laserfiche client does not have an option to use it.

There is not a single WINHTTP error in the trace, only this memo

10:01:25.990 [23224]     WinHTTP Memo: Error 12175 in WinHttpSendRequest.

The entire trace only says one thing all the way down: Internal SSL Error

What is strange is the error code in the memo, 12175 translates to TLS 1.2 is not supported by the operating system. But I am using Windows 10, which nativly supports TLS 1.2 and how did I get to using TLS when I asked for SSL?

Chad, you have actually been using TLS for quite some time and probably didn't realize it. SSL has been dead for years, but people still refer to things as SSL when in fact it is TLS. This article gives a brief overview of what I'm talking about.

Blake is correct. The term "SSL" has come to generally refer to the SSL/TLS family of transport encryption protocols. Any time you see an "SSL" option in Laserfiche, it means TLS. All of the actual SSL protocols are depreciated.

Since you're getting an explicit WinHTTP error message, I'd try setting the WinHttp TLS 1.2 registry keys described in this Configuration Information for TLS 1.2 KB article.

Follow the steps here to update your machine to use TLS 1.2 as the default. Try the "Easy fix" solution if you are not comfortable editing the registry manually.

Thanks Blake, that is pretty crazy. I always thought of them as 2 different protocols where you have to specify the correct one. I knew TLS was "more" secure but didn't know it was ever referred to as SSL. They should have just called it SSL 4.x

I am using Windows 10, which doesn't have a \Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp in the Wow6432 Node

I checked under Internet Properties and it has Use TLS 1.0, 1.1, and 1.2 checked. Are you simply asking me to uncheck the 1.0 and 1.1? That would be a lot more straight forward.

Can I configure which TLS to use in the Admin console?

Chad, here's a long answer to your question wby means of illustrating the underlying mechanisms at work:

It's often useful to understand that TLS connections are negotiated in a "TLS handshake" between both parties. The negotiation algorithm is designed to find the strongest protocol (e.g. TLS 1.2) and cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384; TLS 1.2 supports 37) that both parties support.

If we abstract this to a human conversation, it would go something like this:

1. Chad: Hi, I'm Chad the Client. I support TLS versions 1.2, 1.1, and 1.0. I support cipher sites A, B, C, D, and E. ("client hello")
    
2. Sam: Hi, I'm Sam the Server. I support TLS version 1.2 too, so we'll use that since it's the highest version we both support. We will use cipher suite A for similar reasons. ("server hello")
   Also, here is my server certificate for you to verify.
    
3. <cryptography ensues>

Disabling TLS 1.1 and 1.0 on either side will not affect the end result of the handshake (using TLS 1.2) because it always negotiates the highest mutually supported version.

-----------

Important Note: There are significant general security concerns around leaving TLS 1.0 and 1.1 enabled on a machine. If at all possible, you should disable them. All major browsers have depreciated them for a reason. This example simply shows why disabling the lower protocol versions does not affect a TLS handshake between a client and server that both support TLS 1.2.

If a server has TLS 1.0, 1.1, and 1.2 enabled, an attacker can simply claim that TLS 1.0 is the highest version they support and negotiate the server down to it so they can exploit TLS 1.0 vulnerabilities.

Having TLS 1.0 & 1.1 disabled at the OS-level on both sides also provides confidence that the communications are not using those insecure protocols.

-----------

If instead the server supports TLS 1.1 and 1.2 and the client requires TLS 1.2, the conversation goes like this:

1. Chad: Hi, I'm Chad the Client. I support TLS version 1.2. I support cipher sites A, B, C, D, and E. ("client hello")
    
2. Sam: Hi, I'm Sam the Server. TLS version 1.1 is the highest I support, so we are not able to agree on a version to use for this conversation, which is now over. ("server hello")

-------------------------------------------------------------------------------------------------------------

As I've described in another post Laserfiche leverages the Microsoft Schannel Security Support Provider (SSP) for cryptography and encryption. Laserfiche 10.4.2 applications use TLS 1.2 by default. Earlier Laserfiche versions may target older versions of .NET Framework that require the registry updates described in KB 1013919: Configuration Information for TLS 1.2.

This is why the instructions we (and Microsoft) provide for enabling TLS 1.2 mostly deal with setting registry keys affecting Schannel (or .NET's use of Schannel). 

If you haven't already, I would set the .NET TLS 1.2 reg keys on both client and server machines as well:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

-------------------------------------------------------------------------------------------------------------

Finally, the easiest way to tell if there are any issues with your server's certificate, or that certificate's binding:

1. Install IIS on the server with LFS, if you haven't already
2. Set the HTTPS/443 port certificate binding, if you haven't already
3. From the client machine, open a web browser and navigate to "https://server.example.com, where server.example.com is exactly the same FQDN you're trying to connect to LFS from the client with.
4. See if the browser throws any certificate/SSL warnings. 

-------------------------------------------------------------------------------------------------------------

Please also let us know which versions of which applications are involved here. Full, native TLS 1.2 support across the Laserfiche suite is still relatively new with the move to .NET Framework 4.7.2+, so what fixes should or should not be required is version dependent.

Hope some of that proves useful.

Disabling TLS 1.1 and 1.0

Got it, so no reason to disable anything, I will leave them all enabled.

Earlier Laserfiche versions may target older versions of .NET Framework

I am using 10.4.1, now downloading 10.4.3 to try it out. But if 10.4.1 targets a different version 1.0 or 1.1 I have got them enabled so I am good to go! I don't really care which version LF uses since Windows 10 supports them all.

This is why the instructions we (and Microsoft) provide for enabling TLS 1.2 mostly deal with setting registry keys affecting Schannel (or .NET's use of Schannel). 

Again I really don't want to hack what the different frameworks use. I support all of them, so any service using any framework will just tell me which one is the highest that it supports, and I will have it ready to go!

This is just my Dev station, so it is a single workstation running Windows 10, LFS, and the Client.

I have a client that wants to do a 3 way secure connection from Forms (SSL Repo Archives, SSL to SQL, and SSL to Workflow). So I am just testing the capabilities before working in their live environment. The problem is, I can't even get past the login and previously I never had an issue enabling SSL, only registry change I had to make was in the Engine/8.0 folder for the Key UseSSL.

Will let you know if installing the latest server/client fixes it.

No luck with the 10.4.3 package. So far the only registry change I made, doesn't actually make any changes though, since you said that the latest version of LF already defaults to TLS 1.2.

I made this change which just defaults to use TLS 1.2

1. From the Windows search bar, use regedit to open the Window Registry Editor.
2. Browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp.
3. Create a new DWORD value named:

   DefaultSecureProtocols

   Set the value in hexadecimal to:

   800

I have no problem using https in a browser. The only complaint I get is specifically about the fact that I don't have a valid authority, because the certificate is self signed.

Please open a support case so we can troubleshoot this further. The next step is to get a winhttp trace:

1. Turn on winhttp tracing on the client machine, from an administrative command prompt:

netsh trace start scenario=internetclient 

(The output for this command should report the location of the trace file)

2. Restart LF client

3. Reproduce the problem

4. Turn off tracing:

netsh trace stop

5. Upload the trace logs to the support case.

Ok I uploaded the netsh trace log to the existing case. I did send them an LFSO trace awhile back too.

Chad, I want to add an important clarification on disabling TLS 1.0 and 1.1.

There are significant general security concerns around leaving TLS 1.0 and 1.1 enabled on a machine. If at all possible, you should disable them. All major browsers have depreciated them for a reason.

The example simply shows why disabling the lower protocol versions does not affect a TLS handshake between a client and server that both support TLS 1.2. If a server has TLS 1.0, 1.1, and 1.2 enabled, an attacker can simply claim that TLS 1.0 is the highest version they support and negotiate the server down to it so they can exploit TLS 1.0 vulnerabilities.

Having TLS 1.0 & 1.1 disabled at the OS-level on both sides also provides confidence that the communications are not using those insecure protocols.

Well right now I can't use any of them, because of the internal error. If I am negotiating with an attacker, I can't see why they would care about decrypting my connection, I am already connected to them! We are more concerned with listeners, internal users who might use a simple free tool like Ettercap to poison the arp.

I think the key to not negotiating with attackers, just means protecting your DNS, which for internal services is easy, for websites requires a certificate authority.

But again, I can't even use encryption right now because of the error, so I am completely unencrypted and am stuck at the first step.

@████████

Somehow I glossed over you mentioning this before:

I have no problem using https in a browser. The only complaint I get is specifically about the fact that I don't have a valid authority, because the certificate is self signed.

WinHTTP code is not like a browser where you can click through an invalid certificate warning. I'm reasonably certain we don't set the WINHTTP_OPTION_SECURITY_FLAGS for "SECURITY_FLAG_IGNORE_UNKNOWN_CA" that would make the client ignore that the server certificate has an invalid Certificate Authority. 

While it seems that in some cases the WinHTTP 12175 error code can indicate a TLS 1.2 issue, Microsoft's WinHTTP Error Messages reference lists:

12175

One or more errors were found in the Secure Sockets Layer (SSL) certificate sent by the server. [...]

There are only a few places in the Laserfiche suite where you can even toggle accepting invalid certificates. One such example is for Workflow connections to external web services:

Unless an option to accept invalid certificates (which includes certs from untrusted certificate authorities) exists and is explicitly enabled for the connection you're trying to make, assume any certificate validity issues will be fatal.

You should try adding that self-signed server cert to the client machine's Trusted Root Certification Authorities certificate store. Validate that Chrome/Edge/IE no longer throw any warning about any aspect of the certificate, then try the Laserfiche connection again. Firefox uses its own certificate store and is thus not useful for this test.

To avoid certificate authority trust issues entirely in the future, I would strongly recommend issuing internal testing certs from an Active Directory Certificate Authority rather than self-signing. It's just as easy (if not easier) and the AD-issued certs are automatically be trusted within the domain.