• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
Locked
0

Adobe Flash SAU update not working (Internally Hosted)

Community Beginner ,
Mar 28, 2018 Mar 28, 2018

Copy link to clipboard

Copied

Linux server hosting Adobe Flash SAU files.

Current Version: 28.0.0.161

Available Version: 29.0.0.113

[root@webserver]# tree /var/www/adobeflash

/var/www/adobeflash

└── pub

    └── flashplayer

        └── update

            └── current

                └── sau

                    ├── 27

                    │   ├── install

                    │   │   ├── install_all_win_64_ax_sgn.z

                    │   │   └── install_all_win_ax_sgn.z

                    │   └── xml

                    │       └── version.xml

                    ├── 28

                    │   ├── install

                    │   │   ├── install_all_win_64_ax_sgn.z

                    │   │   └── install_all_win_ax_sgn.z

                    │   └── xml

                    │       └── version.xml

                    ├── 29

                    │   ├── install

                    │   │   ├── install_all_win_64_ax_sgn.z

                    │   │   └── install_all_win_ax_sgn.z

                    │   └── xml

                    │       └── version.xml

                    └── currentmajor.xml

14 directories, 10 files

Files sourced from: fpdownload2.macromedia.com

/var/www/adobeflash/pub/flashplayer/update/current/sau/29/install

[root@cunifyweb install]# md5sum *.z

7bf22b22395993e3886d1246f8287500  install_all_win_64_ax_sgn.z

47524f66b0399fdc9776f4ccfc6ed2d6  install_all_win_ax_sgn.z

[root@cunifyweb install]#

Adobe Flash Updater Scheduled task is available and running. I've deleted the CheckFrequency registry key a couple times and forced update attempt again as seen in the log below for mutiple attempts and warnings.

C:\Windows\SYSWOW64\Macromed\Flash\FlashInstall32.log:

2018-3-28+14-19-38.96 [info] 1631 /pub/flashplayer/update/current/sau/currentmajor.xml

2018-3-28+14-19-38.116 [warning] 1470 12175

2018-3-28+14-19-38.116 [warning] 1474 183

2018-3-28+14-19-38.116 [warning] 1475

2018-3-28+14-19-38.116 [info] 1432

2018-3-28+14-19-38.116 [info] 1612

2018-3-28+14-19-38.116 [info] 1620

2018-3-28+14-22-24.484 [info] 1629 adobeflash.domain.local

2018-3-28+14-22-24.484 [info] 1614

2018-3-28+14-22-24.484 [info] 1615

2018-3-28+14-22-24.494 [info] 1618

2018-3-28+14-22-24.494 [info] 1619 1063

2018-3-28+14-22-24.504 [info] 1629 adobeflash.domain.local

2018-3-28+14-22-24.504 [info] 1614

2018-3-28+14-22-24.504 [info] 1615

2018-3-28+14-22-24.504 [info] 1618

2018-3-28+14-22-24.504 [info] 1604

2018-3-28+14-22-24.504 [info] 1608

2018-3-28+14-22-24.504 [info] 1631 /pub/flashplayer/update/current/sau/currentmajor.xml

2018-3-28+14-22-24.524 [warning] 1470 12175

2018-3-28+14-22-24.524 [warning] 1474 183

2018-3-28+14-22-24.524 [warning] 1475

2018-3-28+14-22-24.524 [info] 1432

2018-3-28+14-22-24.524 [info] 1612

2018-3-28+14-22-24.524 [info] 1620

2018-3-28+15-0-0.139 [info] 1629 adobeflash.domain.local

2018-3-28+15-0-0.202 [info] 1614

2018-3-28+15-0-0.202 [info] 1615

2018-3-28+15-0-0.202 [info] 1618

2018-3-28+15-0-0.716 [info] 1619 1063

2018-3-28+15-0-1.13 [info] 1629 adobeflash.domain.local

2018-3-28+15-0-1.13 [info] 1614

2018-3-28+15-0-1.13 [info] 1615

2018-3-28+15-0-1.13 [info] 1618

2018-3-28+15-0-1.13 [info] 1604

2018-3-28+15-0-1.13 [info] 1608

2018-3-28+15-0-1.528 [info] 1612

2018-3-28+15-0-1.528 [info] 1620

C:\Windows\System32\Macromed\Flash\FlashInstall64.log:

=O====== M/28.0.0.137 2018-01-13+19-00-07.034 ========

0000 00000044

0001 00000045

0002 00001113 C:\Windows\system32\config\systemprofile\AppData\Roaming\Macromedia\Flash Player\www.macromedia.com\bin\* 3

0003 00000010 "C:\Windows\system32\Macromed\Temp\{8A5D012D-6071-4E92-9E8F-08FA6F7E6F85}\InstallFlashPlayer.exe" -install -skipARPEntry -iv 9 -au 4294967295

0004 00000020 C:\Windows\SysWOW64\FlashPlayerCPLApp.cpl

0005 00001037 SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Adobe Flash Player ActiveX/ 2

0006 00000013

0007 00000015 C:\Windows\system32\Macromed\Flash\FlashUtil64_28_0_0_137_ActiveX.exe

0008 00000016 C:\Windows\system32\Macromed\Flash\FlashUtil64_28_0_0_137_ActiveX.dll

0009 00000023 C:\Windows\system32\Macromed\Flash\activex.vch

0010 00000019 C:\Windows\SysWOW64\FlashPlayerCPLApp.cpl

0011 00000012

=X====== M/28.0.0.137 2018-01-13+19-00-08.714 ========

=O====== M/28.0.0.161 2018-02-10+16-00-07.143 ========

0000 00000044

0001 00000045

0002 00001113 C:\Windows\system32\config\systemprofile\AppData\Roaming\Macromedia\Flash Player\www.macromedia.com\bin\* 3

0003 00000010 "C:\Windows\system32\Macromed\Temp\{A97AC9C4-B8D3-4840-AEEA-6A1F10546B84}\InstallFlashPlayer.exe" -install -skipARPEntry -iv 9 -au 4294967295

0004 00000020 C:\Windows\SysWOW64\FlashPlayerCPLApp.cpl

0005 00001037 SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Adobe Flash Player ActiveX/ 2

0006 00000013

0007 00000015 C:\Windows\system32\Macromed\Flash\FlashUtil64_28_0_0_161_ActiveX.exe

0008 00000016 C:\Windows\system32\Macromed\Flash\FlashUtil64_28_0_0_161_ActiveX.dll

0009 00000023 C:\Windows\system32\Macromed\Flash\activex.vch

0010 00000019 C:\Windows\SysWOW64\FlashPlayerCPLApp.cpl

0011 00000012

=X====== M/28.0.0.161 2018-02-10+16-00-08.812 ========

URL paths are accessible from any workstation computer via port 80 (non-TLS) or 443 (TLS). No issue with dns, connectivity, firewall rules, or any other hinderence found.

Paths return information if the path is correct. IE: there are not permission issues on the server.

SSL Cert is active, valid, CN and other attributes are good. Computers trust the domain CA, CA cert is valid. Path is good for full certificate chain.

Port 80 is also open and accessible at same location without SSL.

https://adobeflash.domain.local/pub/flashplayer/update/current/sau/currentmajor.xml returns:

<version>

<Player major="29" majorBeta="29"/>

</version>

https://adobeflash.domain.local/pub/flashplayer/update/current/sau/29/xml/version.xml returns:

<version>

<ActiveX major="29" minor="0" buildMajor="0" buildMinor="113"/>

<Plugin major="29" minor="0" buildMajor="0" buildMinor="113"/>

<Pepper major="29" minor="0" buildMajor="0" buildMinor="113"/>

<MacPlugin major="29" minor="0" buildMajor="0" buildMinor="113"/>

<MacPepper major="29" minor="0" buildMajor="0" buildMinor="113"/>

<SAUConfig checkFrequency="1"/>

</version>

Views

701

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 1 Correct answer

Community Beginner , Mar 28, 2018 Mar 28, 2018

I found the issue pretty easily once I knew winhttp was in play here. Winhttp by default supports TLS 1.0 only (yuck). I had removed TLS 1.0 and TLS 1.1 from our internal server a short while ago and only serve TLS 1.2.

I tested this a couple of ways, I added back TLS 1.0 and deleted the LastUpdateCheck registry for FlashPlayerSAU and then ran the scheduled task and the update went through. I also put the internal server back to only serving TLS 1.2 and updated the workstation to support TLS 1.2

...

Votes

Translate

Translate
Adobe Employee ,
Mar 28, 2018 Mar 28, 2018

Copy link to clipboard

Copied

Thank you very much for the detailed information and log file output. 

The failure is due to the currentmajor.xml file not being accessible:

2018-3-28+14-19-38.96 [info] 1631 /pub/flashplayer/update/current/sau/currentmajor.xml

2018-3-28+14-19-38.116 [warning] 1470 12175

1470 = WinHttpSendRequest call to currentmajor.xml failed

12175 is the corresponding Microsoft code = ERROR_INTERNET_DECODING_FAILED

WinINet failed to perform content decoding on the response. For more information, see the Content Encoding topic.

For the updates to 28.0.0.137 and 28.0.0.161:  Where those performed using Adobe's server's or your internal server?

Please ensure the CN in the certificate is exactly the same as the domain in the mms.cfg file

Path is good for full certificate chain.

Port 80 is also open and accessible at same location without SSL.

https://adobeflash.domain.local/pub/flashplayer/update/current/sau/currentmajor.xml

SAU uses https for all calls.  Are you able to access this file using https?  It's not clear in your post if you accessed it only via http, or https as well.

Please provide the mms.cfg file that you are using. You can upload the file to cloud.acrobat.com/send and private message the link to me.  To send a private message, click on my user_name link and then on the 'Message' button link.  For reference, include a link to this discussion topic.

Also upload, or post, a screenshot of the certificate with the CN name and Issuer name.

What are the client Windows version(s)?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Mar 28, 2018 Mar 28, 2018

Copy link to clipboard

Copied

Definitely have connectivity and tested across a multitude of workstations. The previous installations all happened with our internal sau host and nothing changed except version 28 to 29. We tested the https link below and even the version.xml link to list the build version. All checks out.

All workstations are Windows 7 Professional x64. They all have the same mms.cfg that they have always had and worked on. Nothing has changed there.

mms.cfg:

AutoUpdateDisable=0

AutoUpdateInterval=1

SilentAutoUpdateEnable=1

SilentAutoUpdateServerDomain=adobeflash.domain.local

SilentAutoUpdateVerboseLogging=1

SSL Cert is active, valid, CN and other attributes are good. Computers trust the domain CA, CA cert is valid. Path is good for full certificate chain. I replaced the cert earlier this month but I went ahead and put the old certificate back in place to make sure that wasn't the issue. The old certificate did the exact same thing. Again no issue there. I can send a pic of the cert but I'm certain the cert (both the older and newer one) are completely fine. The only change on the newer one is we added the Subject Alternative Name field: DNS Name=adobeflash.domain.local. The CN is correct and IE and Chrome both identify and allow the pathing.

https://adobeflash.domain.local/pub/flashplayer/update/current/sau/currentmajor.xml returns:

<version>

<Player major="29" majorBeta="29"/>

</version>

I appreciate the error code resolution you gave me. I will test winhttp as I now know what method you use to do the url calls. I'll report back shortly with my results.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Mar 28, 2018 Mar 28, 2018

Copy link to clipboard

Copied

Thank you for the additional information.  I notified the installer engineer of your original post and will forward the new info to him.


For the mms.cfg file, please do provide us with the actual file you are using, as previously requested.Also provide the certificate screenshot, as previously requested.


Thank you.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Adobe Employee ,
Mar 28, 2018 Mar 28, 2018

Copy link to clipboard

Copied

I posted the wrong 12175 windows code previously.  The correct one is

ERROR_WINHTTP_SECURE_FAILURE

12175

One or more errors were found in the Secure Sockets Layer (SSL) certificate sent by the server. To determine what type of error was encountered, check for a WINHTTP_CALLBACK_STATUS_SECURE_FAILURE notification in a status callback function. For more information, see WINHTTP_STATUS_CALLBACK.

We're still investigating on our end.  Just wanted to give you the correct code info.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Mar 28, 2018 Mar 28, 2018

Copy link to clipboard

Copied

I found the issue pretty easily once I knew winhttp was in play here. Winhttp by default supports TLS 1.0 only (yuck). I had removed TLS 1.0 and TLS 1.1 from our internal server a short while ago and only serve TLS 1.2.

I tested this a couple of ways, I added back TLS 1.0 and deleted the LastUpdateCheck registry for FlashPlayerSAU and then ran the scheduled task and the update went through. I also put the internal server back to only serving TLS 1.2 and updated the workstation to support TLS 1.2 via WinHTTP.

To add support for Windows WinHTTP TLS 1.2 you will need to install kb3140245

Below is a link to an article and the update catalog link

https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-s... 

Microsoft Update Catalog 

Once the update is pushed, the following two registry additions are applied to the workstations. We utilized a machine startup script and added these two lines. 64bit machines require both registries. 32bit machines will not utilize the wow6432node registry.

reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v "DefaultSecureProtocols" /t REG_DWORD /d "2560" /f

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v "DefaultSecureProtocols" /t REG_DWORD /d "2560" /f

After rebooting the workstations to get the registry changes and the LastUpdateCheck registry removed, the update went through.

This could become more prevalent as we near June 30th 2018 (link references slated deadline for TLS 1.0 PCI compliance and likely other compliance standards as well), as TLS 1.0 is highly recommended to be removed from active service. Whether or not internal servers will follow this as well remains to be seen but we have been actively killing TLS 1.0 and some TLS 1.1.

TL;DR:

1) Either make sure you allow TLS 1.0 on your internal server as winhttp ONLY supports TLS 1.0 by default unless you add further support.

2) Add TLS 1.2 support to winhttp on each workstation as described by this post to ensure compatibility in the future. *This option is my recommendation.

Hope this helps someone in the future.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Mar 28, 2018 Mar 28, 2018

Copy link to clipboard

Copied

LATEST

Just to further clarify the registry settings.

I didn't go into extreme detail on the winhttp TLS 1.2 information above. I figure readers could interpret that information further if they want to push out. But I did want to point out that my registry keys allow TLS 1.2 and TLS 1.1 currently as I have it. If you want to tweak what protocols are used, the following information will help. You can also input the registry as hexadecimal or decimal so make sure you know what type of input you are performing and what protocol(s) you want to allow. My recommended post above utilizes the last option below with TLS 1.1 and + 1.2 (preferred).

TLS 1.1:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000200

TLS 1.2:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

TLS 1.1 + 1.2 (Preferred option):

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000a00

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines