Question

HTTP WebRequest 500 (SendFailure) Error With OAuth2 API With Bearer Token

Workflow

Updated September 28, 2020

asked on August 19, 2020 • Show version history

I'm trying to get connected from LFWorkflow to a an API for a third-party vendor we utilize.

I'm able to get LFWorkflow to connect to their authentication API and retrieve the JWT token, but then when I try to complete the next stage of their process to their regular API (a GET request using that JWT token) it just fails every time, no matter what I try to do.

When I test the request using apitester.com it works just fine.

But when I try to run the request through the HTTP Web Request tool in LFWorkflow, it fails every time.

Has any one seen this issue before, and have any suggestions on other things that I can try?

Thank you.

EDIT: I'm on Workflow 10.2.1

0 0

Answer

SELECTED ANSWER

replied on August 20, 2020 • Show version history

Yep, no issue with those software versions. Shouldn't affect Forms 10.4.4.444 at all since it targets .NET 4.7.2 and uses TLS 1.2 by default already.

If for whatever reason something stops working afterward, grab a copy of the IIS Crypto utility on the server. It's a nice GUI for flipping Schannel reg keys. Apply the "Best Practices" template which will re-enable TLS 1.0 and 1.1 but not ancient broken ciphers and work from there.

Your web client BP invocation issue sounds like the web client server only has TLS 1.2 enabled for client protocols while Workflow 10.2 (sans registry update) will only use TLS 1.0 and 1.1 server protocols, so the TLS handshake negotiation fails when they can't find a mutually supported version. Upgrading Workflow to 10.4.2 or applying the reg keys for Workflow 10.2 will likely resolve that one.

For reference, the two keys that enable older .NET Framework apps to use TLS 1.2 are:

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

1 0

Replies

replied on August 19, 2020

Quick hint: Look at TLS 1.2 on your workflow machine

2 0

View 4 previous replies

replied on August 20, 2020

Thanks for the suggestion @████████ - I think you might be right...

Based on your suggestion, I found this: https://support.laserfiche.com/kb/1013919/configuration-information-for-tls-1-2

which lead me to several other pages (links at the bottom of that page).

This is going to take some work...

0 0

replied on August 20, 2020

Right - "the underlying connection was closed" means the problem was at a lower level than HTTP. TLS 1.2 is a good guess, though it could also be some kind of TCP problem. Wireshark can help you get more insight if you want to be sure it's TLS before diving in.

1 0

replied on August 20, 2020 • Show version history

@████████

Workflow 10.4.2 uses TLS 1.2 by default by merit of targeting .NET Framework 4.8. All those registry keys in the TLS 1.2 KB are only necessary for applications that target .NET Framework versions lower than 4.7. Consider upgrading Workflow if that's an option.

Edit (9/14/20): Removed attached .reg file as it changed more than necessary and caused Forms/Workflow communication issues. Reference the two specific registry keys in the accepted answer instead.

Else, grab of copy of the attached .reg file, drop the ".txt" extension, and run it on your Workflow server. It'll set all the TLS 1.2 and .NET keys you need (and disable older insecure protocols and ciphers). Restart the server after applying for the settings to take effect.

1 0

replied on August 20, 2020 • Show version history

Would this registry file be safe to run on a dual purpose Forms & Workflow server combo?

Workflow 10.2

Laserfiche Forms Professional Version 10.4.4.444

I've been battling a similar response error that appears in Laserfiche Web Client after attempting to launch a Business Process manually.

Entry 'AP Batch Auditing [AFA-EBS]' resulted in error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Running an NGINX reverse proxy for all web services, but I don't believe it's involved in this issue at this point. I'd just like to be sure I won't potentially break any Forms services when I attempt this fix by using the 'ServerHardeningKeys.reg' file.

I can provide more information on the environment if necessary.

0 0

SELECTED ANSWER

replied on August 20, 2020 • Show version history

Yep, no issue with those software versions. Shouldn't affect Forms 10.4.4.444 at all since it targets .NET 4.7.2 and uses TLS 1.2 by default already.

For reference, the two keys that enable older .NET Framework apps to use TLS 1.2 are:

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

1 0

replied on August 21, 2020

Thank you @████████ - I was aware that upgrading would resolve. But I'm always reluctant to upgrade as I don't have a test environment to try it in first.

Ultimately, this request came from my boss, and he's in-charge of server configuration and security, so I've punted it back to him to decide how badly he actually wants this API integration.

0 0

replied on August 21, 2020

Gotcha. I would stress that setting only those two .NET registry keys will do the trick for Workflow 10.2 and is about as low-risk/low-impact as you can get. Microsoft instructs people do so for even their own software (see example: Enable TLS 1.1 and TLS 1.2 support in Office Online Server).

1 0

replied on September 8, 2020

I upgraded LFWorkflow to 10.4.2.246 over the weekend, but I'm still seeing the same issue. Any other suggestions?

0 0

View 9 previous replies

replied on September 8, 2020

Hey Matthew, sorry to hear the upgrade didn't resolve the issue for you. Exact same error message? If you're able to post the actual stack trace that would be helpful as well.

0 0

replied on September 8, 2020

I've never had to do that before, how would I go about getting a stack trace from Workflow?

0 0

replied on September 8, 2020

Workflow Admin Console -> Monitoring -> Error Logs -> [Select] -> [View]

I suspect it would be in "activity errors.log" since it's surfacing through a Web Request activity, though "communication.log" is also a possibility.

1 0

replied on September 8, 2020

Weird. It doesn't appear to be putting this error in those logs. I can see plenty of other errors, but nothing newer than early this morning - regarless of the fact that I've run a dozen or more tests of this item since then.

0 0

replied on September 9, 2020

I rebooted the server overnight, just in case that made a difference, it didn't. I'm still getting the error, and it's still not showing up in the Error logs.

0 0

replied on September 9, 2020

I even went ahead and installed the registry entries (ServerHardeningKeys) even though they shouldn't be necessary on 10.4.2, and it's still not working.

0 0

replied on September 9, 2020

Never mind - those registry changes broke the connection between LFForms and LFWorkflow - so I reverted back to the original.

0 0

replied on September 9, 2020

I also tried some testing with another vendor's API, and I get a similar (but slightly different) error message.

0 0

replied on September 9, 2020

While I hate to ask this, do you know how to take a Wireshark trace?

If you can take one that's filtered to the failing API call(s), I can look at it and read exactly why the TLS handshake is failing.

0 0

replied on September 9, 2020

I haven't even heard of that before unfortunately.

If it helps, I can reach out to my VAR and see what they can help with.

1 0

replied on September 9, 2020

Good call, that would be best at this point. If necessary, they can open a formal support case on your behalf and reference this thread as background info.

Thanks for your patience troubleshooting this issue as well. Upgrading Workflow and/or applying the TLS 1.2 reg keys does resolve that error the majority of the time so trying those first was still worthwhile.

1 0

replied on September 9, 2020

Thanks for your help @████████.

If/when we figure it out, I'll update here.

1 0

replied on September 14, 2020

To sum up the response on the ticket our VAR sent to Laserfiche - they basically said that integrating with a third-party API was out of scope, so they couldn't assist me - but that I should go back and try those two registry edits that were posted here...

When I saw that, I'd already been working on some tweaks on the server, things like reinstalling some of the .NET components. So I came back to this post, and I re-read everything. I realized that I hadn't actually tried those two registry edits that @████████suggested. I did try the "Server Hardening" entries, and ended up reverting them when it caused all of the Workflows started by LFForms to terminate. But I didn't try those two stand-alone entries:

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

I had taken that post to mean that I could try those -or- I could try upgrading to 10.4.2. After discussing with my boss, we decided to try the upgrade to 10.4.2. When that didn't work, it didn't occur to me to go ahead and try those two registry entries anyway - I'd taken it as a "do this -or- do that" decision and I'd already done one of the items, so I just didn't think to try the other. 🤦‍♂️

So, I made those changes, and I rebooted, and I'm not getting that same error anymore. One of the two APIs is actually returning data now. The other is still giving me an error, but it's more like an error about a malformed request, so I don't believe it is related.

Although it is possible that the .NET reinstalls I did could have been the fix for the issue, I do suspect that the registry entries were the fix, so I'm going to mark that post as the answer.

Once again, thank you for your help Samuel, and my apologies for not heeding your advice the first time around.

0 0

replied on September 14, 2020

@████████

Thanks for the update and I'm glad to hear everything seems sorted out now. I went back and edited my earlier post to remove the ServerHardening.reg file and direct future readers to use the two specific reg keys above instead.

Cheers,
Sam

1 0

You are not allowed to follow up in this post.

Question

Question

HTTP WebRequest 500 (SendFailure) Error With OAuth2 API With Bearer Token

Answer

Replies

Sign in to reply to this post.