Flash Background Updates from internal server not working

[matts54643606]

We are setting up to receive flash background updates from an internal server for our 5000+ enterprise pcs running windows 7 64bit and Windows 10

Current mms.cfg

AutoUpdateDisable=0
SilentAutoUpdateEnable=1
SilentAutoUpdateServerDomain=SVRTSTR2
SilentAutoUpdateVerboseLogging=1

Note- the server is running server 2016, with IIS, and the website is set up with an SSL certificate and the cab files were extracted to the site with the correct folder structure

Here is the log:

2018-1-3+3-4-0.217 [info] 1629 SVRTSTR2

2018-1-3+3-4-0.220 [info] 1614

2018-1-3+3-4-0.222 [info] 1615

2018-1-3+3-4-0.224 [info] 1618

2018-1-3+3-4-0.226 [info] 1604

2018-1-3+3-4-0.226 [info] 1608

2018-1-3+3-4-0.227 [info] 1612

2018-1-3+3-4-0.232 [info] 1620

2018-1-3+4-4-0.198 [info] 1629 SVRTSTR2

2018-1-3+4-4-0.199 [info] 1614

2018-1-3+4-4-0.201 [info] 1615

2018-1-3+4-4-0.204 [info] 1618

2018-1-3+4-4-0.207 [info] 1619 1063

2018-1-3+4-4-0.228 [info] 1629 SVRTSTR2

2018-1-3+4-4-0.232 [info] 1614

2018-1-3+4-4-0.234 [info] 1615

2018-1-3+4-4-0.236 [info] 1618

2018-1-3+4-4-0.238 [info] 1604

2018-1-3+4-4-0.238 [info] 1608

2018-1-3+4-4-0.238 [info] 1612

2018-1-3+4-4-0.239 [info] 1620

2018-1-3+5-4-0.181 [info] 1629 SVRTSTR2

2018-1-3+5-4-0.181 [info] 1614

2018-1-3+5-4-0.184 [info] 1615

2018-1-3+5-4-0.186 [info] 1618

2018-1-3+5-4-0.190 [info] 1619 1063

2018-1-3+5-4-0.212 [info] 1629 SVRTSTR2

2018-1-3+5-4-0.215 [info] 1614

2018-1-3+5-4-0.217 [info] 1615

2018-1-3+5-4-0.219 [info] 1618

2018-1-3+5-4-0.220 [info] 1604

2018-1-3+5-4-0.220 [info] 1608

2018-1-3+5-4-0.228 [info] 1631 /pub/flashplayer/update/current/sau/currentmajor.xml

2018-1-3+5-4-0.320 [warning] 1470 12175

2018-1-3+5-4-0.321 [warning] 1474 183

2018-1-3+5-4-0.321 [warning] 1475

2018-1-3+5-4-0.322 [info] 1432

2018-1-3+5-4-0.322 [info] 1612

2018-1-3+5-4-0.323 [info] 1620

2018-1-3+6-4-0.259 [info] 1629 SVRTSTR2

2018-1-3+6-4-0.260 [info] 1614

2018-1-3+6-4-0.263 [info] 1615

2018-1-3+6-4-0.265 [info] 1618

2018-1-3+6-4-0.268 [info] 1619 1063

2018-1-3+6-4-0.295 [info] 1629 SVRTSTR2

2018-1-3+6-4-0.297 [info] 1614

2018-1-3+6-4-0.299 [info] 1615

2018-1-3+6-4-0.301 [info] 1618

2018-1-3+6-4-0.303 [info] 1608

2018-1-3+6-4-0.303 [info] 1604

2018-1-3+6-4-0.303 [info] 1612

2018-1-3+6-4-0.304 [info] 1620

2018-1-3+7-4-0.328 [info] 1629 SVRTSTR2

2018-1-3+7-4-0.328 [info] 1614

2018-1-3+7-4-0.331 [info] 1615

2018-1-3+7-4-0.333 [info] 1618

2018-1-3+7-4-0.335 [info] 1619 1063

Please assist

NOTE:

-I have already tried deleting the reg key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Macromedia\FlashPlayerSAU\LastUpdateCheck

-I have imported the Cert to the Trusted Root Certification Authorities store (local computer) on the workstation

I can view the files on a browser(firefox/chrome/IE11) from the workstation by entering https://svrtstr2/ --I get the IIS landing page, and can navigate the folder strucure all the way through without error

[_maria_]

The Background Update service uses the WinHTTP API.  Based on the API documentation, self-signed certs should work, but it's not working in your environment as it keeps returning error 12044 (server requesting client authentication).  You can continue to troubleshoot the error and attempt to resolve it.  As an alternative you can try using a cert from trusted third party certificate authority.  Assuming everything is configured correctly, it should work.

[jeromiec83223024]

If you're self-signing certificates, every client connecting to that SSL server needs to have your self-issued public CA certificate installed and trusted in their system keychain.  It's not enough to just self-sign a cert and put it on the server.  Something in that key's trust chain has to already be trusted by the local system.  Otherwise, it's just like a stranger walking up and saying "Oh hey, give me your car keys for a minute.  It's cool though.  I'm trustworthy, because I have this piece of paper I printed at home that says I'm cool, and I'm totally not going to steal your car."

The thing that you're paying for when you buy a certificate, is for a trusted, independent authority say that you're cool.  Depending on the type of certificate they issue, there are varying levels of trust expressed in that relationship.  The reason that you don't have to install anything in the client in that instance, is because their public keys are already built into the operating system.  They're established, trusted authorities that the operating system vendor recognizes as such, and so the vendor distributes their keys as part of the OS (and updates them periodically through OS updates).

That said, you don't even need to pay for an SSL certificate if cost is an issue.  You can get a free one at letsencrypt.org.  It's so much better than messing around with self-signed stuff.

[matts54643606]

Hello! Thanks for the good advise. I did try to use the letsEncrypt certificate- but ran into this problem:

I think maybe the issue is that the website is not accessible publicly--it's only accessible within our closed corp network.....

any ideas?

[matts54643606]

I found this answer:

# re: Using Let's Encrypt with IIS on Windows

@Vicky - Lets Encrypt uses domain validation which means the domain has to be visible to the public to verify ownership. Basically you have to run LE on a server that responds to that domain.

So you can't use it unless you expose your IP to the Internet. Perhaps you can do it temporarily to get the certificate and then close if off again, but then Updates also won't work (unless you open it up again).

https://weblog.west-wind.com/posts/2016/Feb/22/Using-Lets-Encrypt-with-IIS-on-Windows

so.......I guess I'm confused- whats the point of hosting the updates on a public internet server--- if that was the goal I could simply ask for the updates straight from adobe servers? I thought this was a solution for hosting the updates and serving them out in a closed - private- network?

[jeromiec83223024]

Lets Encrypt was just a suggestion because it was free, and you didn't want to pay for something.  I didn't realize that it had the public requirement.  Sorry about leading you down a dead end.

There are definitely commercial CA services that will work behind an Intranet (Verisign Intranet Certs come to mind).  You should also be able to use a self-signed SSL cert, as long as you want to deploy your signed CA cert to your clients as a prerequisite.  That seems like way more work than is worth it compared to just buying an SSL Certificate, but it's not my budget.

[matts54643606]

Thanks for the info---I'm wondering why my original signed cert is not working- I imported it into the trusted store on the client....anyways- I guess I'll just have to ask for a paid SSL and try it that way.

[jeromiec83223024]

The quick sanity check is to just see if your browser will show the lock icon when you go to the offending URL:

https://flashupdates.charlie.kaplaninc.com/pub/flashplayer/update/current/sau/currentmajor.xml

If it does, and the browser throws up the contents of the xml file (you may have to view source), then we should really be loading it too.  If you have the TLS configuration really tight, like you're only allowing a small subset of protocols and ciphers, it would be interesting to know what those are.  I'd be interested in trying to replicate it.

In Flash Player proper, we're usually delegating all of that to the browser, but in the auto-updater, we may be missing support for a particular TLS feature or something that you're using.  I can't think of a lot of other good reasons for why it would be failing only in our installation toolchain.

If you go to the URL and the browser throws an error, then you probably have a problem that needs to be fixed.  The browser might also give you some more useful feedback about what's failing (e.g. whether it's your webserver configuration or your certificates).  Check the detailed errors, and/or the console and/or seceurity tab in the developer tools. They usually have pretty explicit errors.

For what it's worth, self-signing is obnoxiously complicated.  I've been playing with this stuff since the late '90s, and I do it just infrequently enough to not remember exactly how I did it the last time.  My workflow usually involves a lot of cussing and reading the OpenSSL docs while I'm regenerating the appropriate keys for the third time. 

[jeromiec83223024]

Maria clued me into what's going on.  I didn't catch it when I skimmed the thread, sorry.

The error being returned is from WinHTTP:

ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED

You can configure a webserver to require a certificate for client authentication.  (e.g. instead of having the client log in via username/password to get to a page, they provide a certificate that you issue, and that they install).

It sounds like you have client certificate authentication enabled in your IIS configuration, and you don't want to do that. 

In step 3 here, set it to Ignore or Allow, not Require:

https://blogs.msdn.microsoft.com/asiatech/2014/02/12/how-to-configure-iis-client-certificate-mapping...

[matts54643606]

Here is a screen of the settings as they were

Also- I can pull up the xml in the browser with no error message:

and here is some other info:

[matts54643606]

Here is the latest from the log---any ideas?

Also-I'll note that the cert I have is a .pfx file

2018-1-31+11-30-1.15 [info] 1629 flashupdates.charlie.kaplaninc.com

2018-1-31+11-30-1.15 [info] 1614

2018-1-31+11-30-1.15 [info] 1615

2018-1-31+11-30-1.30 [info] 1618

2018-1-31+11-30-1.30 [info] 1604

2018-1-31+11-30-1.30 [info] 1608

2018-1-31+11-30-1.30 [info] 1612

2018-1-31+11-30-1.30 [info] 1620

2018-1-31+12-30-0.904 [info] 1629 flashupdates.charlie.kaplaninc.com

2018-1-31+12-30-0.936 [info] 1614

2018-1-31+12-30-0.951 [info] 1615

2018-1-31+12-30-0.967 [info] 1618

2018-1-31+12-30-0.982 [info] 1619 1063

2018-1-31+12-30-1.14 [info] 1629 flashupdates.charlie.kaplaninc.com

2018-1-31+12-30-1.14 [info] 1614

2018-1-31+12-30-1.14 [info] 1615

2018-1-31+12-30-1.29 [info] 1618

2018-1-31+12-30-1.29 [info] 1604

2018-1-31+12-30-1.29 [info] 1608

2018-1-31+12-30-1.29 [info] 1612

2018-1-31+12-30-1.29 [info] 1620

2018-1-31+13-30-0.903 [info] 1629 flashupdates.charlie.kaplaninc.com

2018-1-31+13-30-0.935 [info] 1614

2018-1-31+13-30-0.950 [info] 1615

2018-1-31+13-30-0.966 [info] 1618

2018-1-31+13-30-0.982 [info] 1619 1063

2018-1-31+13-30-1.13 [info] 1629 flashupdates.charlie.kaplaninc.com

2018-1-31+13-30-1.13 [info] 1614

2018-1-31+13-30-1.13 [info] 1615

2018-1-31+13-30-1.13 [info] 1618

2018-1-31+13-30-1.13 [info] 1604

2018-1-31+13-30-1.13 [info] 1608

2018-1-31+13-30-1.13 [info] 1612

2018-1-31+13-30-1.13 [info] 1620

2018-1-31+14-30-0.911 [info] 1629 flashupdates.charlie.kaplaninc.com

2018-1-31+14-30-0.942 [info] 1614

2018-1-31+14-30-0.958 [info] 1615

2018-1-31+14-30-0.974 [info] 1618

2018-1-31+14-30-0.989 [info] 1619 1063

2018-1-31+14-30-1.20 [info] 1629 flashupdates.charlie.kaplaninc.com

2018-1-31+14-30-1.20 [info] 1614

2018-1-31+14-30-1.20 [info] 1615

2018-1-31+14-30-1.36 [info] 1618

2018-1-31+14-30-1.36 [info] 1604

2018-1-31+14-30-1.36 [info] 1608

2018-1-31+14-30-1.36 [info] 1631 /pub/flashplayer/update/current/sau/currentmajor.xml

2018-1-31+14-30-1.255 [warning] 1474 12044

2018-1-31+14-30-1.255 [warning] 1475

2018-1-31+14-30-1.270 [info] 1432

2018-1-31+14-30-1.270 [info] 1612

2018-1-31+14-30-1.270 [info] 1620

[jeromiec83223024]

From your logs:

2018-1-31+14-30-1.36 [info] 1631 /pub/flashplayer/update/current/sau/currentmajor.xml

2018-1-31+14-30-1.255 [warning] 1474 12044

2018-1-31+14-30-1.255 [warning] 1475

1474 = WinHttpReceiveResponse call to currentmajor.xml failed

1475 = Could not retrieve currentmajor.xml

12044 is Microsoft’s ‘ERROR_WINHTTP_CLIENT_AUTH_CERT_NEEDED’ code

Your IIS server is requiring a client certificate for the file at /pub/flashplayer/update/current/sau/currentmajor.xml.  Those SSL Settings can be applied at the directory level, so you might not be requiring a client cert at the site level, but my guess is that it gets enabled somewhere along this path.  I'd just walk down each directory and check the SSL settings on each. 

[matts54643606]

They were all set to Accept-- except for the top Default website- which was set to Ignore- I changed it to Accept

I cant help thinking its something in IIS?

From a client machine I can browse to the xml file- if I click the lock icon I get this:

[matts54643606]

could it be something in my network blocking it? I have installed wireshark and can run a capture - would that be helpful?

[jeromiec83223024]

I don't know enough about your environment.  It's a Windows API throwing the SSL handshake error about the missing client SSL certificate.  I tend to believe that we're getting the request for that client certificate, especially since it's the underlying Windows API that's throwing the error about it.

If you guys proxy all of your browser traffic through a security appliance or something, that might explain it.

You might get a sense of it from looking at Wireshark, e.g. is the response to the HTTPS request actually coming from the IP that you expect.  Is it coming from the same IP when you hit it in the browser vs. when you hit it with the installer, etc.

[matts54643606]

[jeromiec83223024]

That's just telling you that whatever IE is doing behind the scenes to render the XML all pretty like that is "compromising HTTPS security" because it wasn't also delivered over HTTPS.  It's not telling you anything about what's actually going on.

Did you glean anything useful from wireshark?

[matts54643606]

not really--I did have a thought though---could the fact that we disable SMB have any effect. what about RC4?

[jeromiec83223024]

No, sorry.  When we attempt to retrieve the XML file, the server is requiring a client-side authentication certificate, and the request fails.  It's a configuration issue.  Do you have someone on staff that's really good with IIS and network debugging tools?  You might have them take a look and see what's different about the requests when the browser makes them vs. the installer.  I think that would be very telling.  As an aside, something like Charles Web Proxy might be more friendly than Wireshark, particularly for debugging HTTPS traffic.