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
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
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
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
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>
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
...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)?
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.
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.
Copy link to clipboard
Copied
I posted the wrong 12175 windows code previously. The correct one is
ERROR_WINHTTP_SECURE_FAILURE
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.
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
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.
Copy link to clipboard
Copied
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