mixit

I thought you were using -a sha1 to begin with? In any case, I'm glad it worked out in the end. BTW, it turns out that if you want to use -a sha256|sha384|sha512 on XP, you can do so by adding -sp "Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)" -sy 24 (24 is PROV_RSA_AES type), and of course you can use -len 2048|4096 for longer keys. The CSP makecert defaults to doesn't have SHA-2, hence the NTE_BAD_ALGID (0x80090008) errors. http://www.msfn.org/board/topic/176299-latest-version-of-software-running-on-xp/ has a bunch, even if the list is spread all over the topic. (In fact, had occurred to me to look there first, I wouldn't have had to hunt down procmon on my own.)

Windows Embedded POSReady 2009 is an XP flavor with a few added features that is still getting official updates from Microsoft until early 2019. These updates can very easily be used on regular XP, so far with no real compatibility issues (that I can recall, anyway). This very forum here happens to have some mighty good ongoing coverage on this subject. The Microsoft Windows SDK for Windows 7 and .NET Framework 4 that you linked to above contains the 6.1.7600.16385 I have (GRMSDK_EN_DVD.iso, \Setup\WinSDKTools\WinSDKTools_x86.msi). I didn't notice before that you're (apparently) using a version from Microsoft Visual Studio 8 SDK v2.0. Using the newer version might make a difference. The current v3.40 from MS no longer works with XP, but you still can get v3.20 from archive.org. Set your filter to Include when Process Name "is" makecert.exe, run makecert, and go from there - the interface is pretty self-explanatory, assuming you have some idea about registry and file API calls. (It usually makes sense to turn capturing off as soon as you've run whatever you're interested in, leaving it on while you browse the log will just put needless load on the system.) I don't know off the top of my head what those errors could be about and I'm sure you can google just as well as I could. Good luck!

Welcome to the forum! FWIW, your exact command works fine on my XP SP3 with POSReady updates. I don't actually have the SDK properly installed, only the tools manually extracted from the installer into a C:\Program Files subfolder. My makecert.exe version is 6.1.7600.16385. I'm logged in as a member of the local Administrators group, so I just ran this in my regular command prompt. I got prompted to create a private key password (at which point root.pvk had been created but was empty; the file got filled in after completing the dialog), then to enter said password (after which root.cer was created). When I disabled my Write permission for the folder, I got two error messages: "Error: Unable to create file for the subject ('root.pvk')" plus the one you saw. Might want to try tracing the execution with Sysinternals Process Monitor (procmon) to narrow down which registry keys and/or files makecert seems to have a problem with. Judging from my output when I ran the command without the " -ss Root -sr localMachine" part (since with the error you're seeing you'd never get to updating the cert store). the only file writes (except for the .pvk and .cer, and directory updates) seemed to be two files that were created and later deleted under ?:\Documents and Settings\username\Application Data\Microsoft\Crypto\RSA\S-*, and you say you've already checked the permissions there. There also seemed to be no registry writes in this case.

1.4.8.1008 seems to be needing a few post-XP API functions (12 from kernel32.dll, 2 from dbghelp.dll) so what's probably happening is that when Chrome "detects" and lists it, it's just checking that all the plugin files are there and reading the manifest data, but when it's time to actually use the plugin, it won't load on XP. 1.4.8.903 seems fine in this regard. (I don't use Chrome myself, this is just based on static analysis.)

Simply spoofing the user agent won't work in this case, because (at least right now) it doesn't look like they're blocking IE8 based on its UA, they really seem to be doing it by the encryption method, so the POSReady AES update is still needed. When I tested with IE8 earlier, I was getting the warning page every few page loads when i disabled AES128-SHA and left only 3DES, whereas I couldn't get it to appear at all when I disabled 3DES and re-enabled AES128-SHA. I also tried it with a spoofed IE9 UA just now and it made no difference, the warning page still appeared periodically without AES128-SHA. (I did see @dencorso suggesting UA spoofing earlier, but the way that whole thing got sidetracked into a .reg file line endings discussion, its point had disappeared from my mind by the time I got to running my initial tests.)

EDIT: FWIW, I wrote this reply before this whole opera was consolidated into its own thread; JodyT's comments seemed (to me) rather strikingly off-topic and pointless in the context of the thread they initially appeared in. One of the reasons I personally tend to at these types of posts of yours is that IIRC you've mentioned a number of times how you used to really hate some newer Windows versions, and how now you've learned to like them and "moved on" from XP, with a strong implication that everyone should do the same. Somehow, the way you present it comes across as a religious argument, about how you used to believe in a wrong god but now you've found the right one and everyone should do the same. For starters, logically a big part of "moving on" would be that you don't keep coming back to lecture those who are now in the "wrong" from your point of view. I assume the reason most people say harsh words about Windows 10 is because they've tried it and strongly dislike certain aspects of it and MS behavior surrounding it. It's a fresh experience for them, often an ongoing one, they haven't "moved on" from it years ago. That's completely different from your self-described situation with XP. Then, I think virtually none of the regulars here are still on vanilla XP, they have all gone down the POSReady 2009 route. So talking about it as if people who are (for all intents and purposes) using a product still supported by MS - with updates coming out every month just as for any other supported Windows version - are irresponsible and a major threat to the Internet or whatnot is simply twisting the reality. A lot of the people here are more than capable of determining whether or not their choice of OS is a risk to them and the world at large or not - and they're unlikely to appreciate implications to the contrary. Wait until after the POSReady EOL. maybe? And finally, why does there have to be something irrational about someone still using XP, can't it be a perfectly rational decision? If it still does everything we need (and doesn't do what we don't want), why shouldn't we keep using it? As I think I've already said in a similar discussion in the past, we live in the age of virtualization and can and do use other OS-s in parallel to XP whenever such a need arises. i know that should XP outlive its usefulness for me and become a hindrance or an unacceptable security risk, I will stop using it as my main OS, no question about it. But I'm not going to do so because of marketing speak, scare tactics, artificial crippling of software, or anyone's proselytizing, and I think many people here feel the same.

@Tacit I'm not sure what's going on in your case, but there are unfortunate cases of Primetime failing to work no matter what. I don't think I've ever seen them fully spelled out by Mozilla, but I've seen mentions of AMD chips and non-SSE2 Intel chips causing problems. In any case, these problems were widespread enough to hold Mozilla back from ever officially supporting Primetime on XP. Then again, these problems would supposedly be more likely to manifest as plugin crashes than simply not playing media. So, in addition to what @dencorso already suggested (to hopefully free him from having to keep mentioning it, I've now added a case sensitivity note to the opening post ), you may want to try the whole thing out from scratch with a new clean Firefox profile, and if that changes nothing, why not a newer browser version, unless you have specific reasons for sticking with 47.0.2. You may also want to disable all your other plugins while you're testing. In a new clean profile they're all enabled by default , so make sure you turn them off before you try out any sites.

TL;DR, if for some rather unfathomable reason you still really really really want to use IE8 to browse the web (NOT RECOMMENDED, as already stated by several people above), you won't necessarily be locked out from Wikipedia just yet if (like probably most people here) you have installed POSReady 2009 update KB3055973 or, preferably, its successive security fix KB3081320, These updates install TLS 1.0 cipher suites AES128-SHA (TLS_RSA_WITH_AES_128_CBC_SHA) and AES256-SHA (TLS_RSA_WITH_AES_256_CBC_SHA), the former of which is and will remain supported by Wikimedia sites for now. However, Wikimedia makes it pretty clear that this isn't going to last very long: See also the "The end is coming regardless" section at the end of that page. Apparently, AES128-SHA currently averages about 0.22% of their requests vs DES-CBC3-SHA-s 0.11%. As for its removal:

@glnz The unified browser thread may be a better fit for these types of questions, it may even already have some answers . --------------------------- Regarding POSReady 2009, though, I wonder if there's any chance of it getting TLS 1.2 updates the same way Server 2008 SP2 suddenly did last month with KB4019276. Its extended support ends in January 2020 (I think), less than a year after POSReady 2009, so it might not be an unreasonable expectation in the current security climate. Could them working on this possibly be the reason IE updates were skipped last month? Probably wishful thinking but I guess we'll see soon enough.

Much appreciated, I've added the new link to the OP. Is it OK to still keep your link as the primary? I kind of wanted to advertise your site I'm sure someone reading this can create more mirrors. Since your copy already existed, I didn't upload it anywhere else myself because I don't do this sort of thing often enough to have a good handle on which DL sites people prefer these days.

I was alerted to the unfortunate fact that the Primetime plugin package is no longer downloadable from Adobe servers. This means that from now on the plugin can't be installed via Firefox GUI alone. Since Mozilla had warned about this removal, our friend @sdfox7has saved a copy of Primetime in his XP software archive, so people can still get the plugin from there and install it manually. I've updated the OP with instructions for manual install. The DL link is also there.

That may just be an omission in the blog post (I copied the version list from there), both x86 and x64 Vista versions seem to be available at the Catalog site. Edit: Looks like Vista was still supported when this patch initially came out in March. Hard to keep track of all these EOL dates.

Not sure what's going on there, I'm seeing no problems specifically with 52.1.1. If the plugin looks active on the Plugins page and you're only seeing this problem at some specific sites, it could just be a coincidence and the problem could be with whatever player they're using. There have been a few streaming sites that I haven't been able to get working without Flash, but that's not specific to this latest FF version. If your previous version before 52.1.1 was something older than 52.0, there could be a problem with the site's browser version checking logic that you could maybe overcome by spoofing an earlier version number. like 51.0.

Get the Primetime ZIP package from somewhere (like @sdfox7's DL link in the OP), open you profile folder (about:support provides easy access to it), create subfolder gmp-eme-adobe, inside it create subfolder 17, unpack the ZIP file in that folder, restart FF, profit Need to set the usual prefs too, of course.

Official patches have also been released for XP and XP64 (i.e. "plain" versions without POSReady updates). Details at

Didn't see this posted yet, so: The KB4012598 patch for the SMBv1 vulnerabilities exploited by WannaCrypt/WCry ransomware has also been released by MS for the following otherwise no longer supported Windows versions: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64. (Edit: Vista x86 and x64 also have this as Vista was still supported when the initial patches came out in March.) In other words, those still using plain XP without getting on the POSReady update train can now get this SMBv1 patch as well. (For those using POSReady updates, this patch has already been superseded by this month's KB4018466.) There are direct download links in the MS blog post referenced above, or you can get them from http://www.catalog.update.microsoft.com/Search.aspx?q=kb4012598 Edit: For those curious about such things: the code in the patched "normal" XP binaries looks to be exactly identical to their Embedded counterparts, only the timestamps, version numbers, checksums, debug info GUIDs and the installer INF file OS version checks differ.

@Andy Sethmaier Since you didn't have Primetime installed before, don't forget to edit media.gmp-manager.url and replace the %VERSION% part with 51.0. This was mentioned a couple of times earlier in the thread, but since I've been lazy, I hadn't yet added it to the opening post by the time you first read it.

As I've been focused on regular 32-bit XP, I can't say I'm up to date on what the differences are between all the platforms. Most platforms only need these plugins for actual DRM content, not regular MP4 playback. Haven't done any research re: 64-bit XP either FWIW, here's a bunch of download URLs for all the various platforms, generally you just have to change the FF version numbers to get the latest DL links. Based on this, I don't think it's necessary (or feasible) to try all possible combinations, but in any case this JS code shows where the values are taken from. You'd have to search through DXR for further details.

Welcome to the MSFN forums, Andy ! You will not lose your Flash unless you explicitly disable or uninstall it. Installing Primetime doesn't do that, so you're OK. media.*.forceSupported settings were added to GMP plugins to ease Mozilla's own testing on platforms not yet officially supported. media.gmp-eme-adobe.forceSupported has been required to enable Primetime on XP since Firefox 49.0 and has been listed in the opening post since then, it's not something new. If @XPPOS2009 meant that installing ESR 52 removed this pref and it had to be re-added, that would be a new thing, but either way it's a known required pref.

Curiouser and curiouser... Since @Dave-H and @5eraph both got a new authroots.sst, I tried again via a Tor proxy and sure enough, I got a new one this time. However, that particular MS cache didn't have the new roots.sst, but did have the new updroots.sst I got before. Apparently we can't trust that MS servers are properly synced. Below are the SHA-256 sums of what I have now, are yours the same? f791d5d50d72af8a804f035f06d6c4df4b880734bdb0758b802bb9b6a50fbd9b *authroots.sst d81a9be65cbcc042c27b7892afa530ac87605a91bcf97ac446d6c37cfed10d5c *delroots.sst 5fba6710bf183bae86e41d9300614f4baeb91da677b503d4622376c434b2cae5 *disallowedcert.sst 22d619f7cab05a2d51d4a9db71694d88e66189d221b72d249a3821bea179ba9c *roots.sst 711068329f6ff50b7b9eb2418638bf9ee6cfc44e2d711b5fa1edbe68375b103c *updroots.sst

Did you mean "updroots.sst and roots.sst"? Not trying to be nitpicky, I just want to determine if this is yet again a case of MS file caches being out of sync around here. (Last year there was one time it took over a week for the updated files to become available here, even though everyone else seemed to be getting them OK.) As of now, I'm not seeing an authroots.sst update, but I am seeing a new updroots.sst.

So, the channel switch to esr has now happened with the release of 52.0. Curiously, they're still allowing normal/non-ESR 52.0 standalone installers (available at Mozilla's FTP site) to upgrade previous versions, even though the internal updater forces the esr switch and the main download portal offers XP users ESR versions as well.

If people are seeing memory leaks, they should report them on Bugzilla, because 52.0 ESR is still supposed to work with all NPAPI plugins, that's kind of the whole point of leaving them enabled there as opposed to the regular 52.0 (where they can still be enabled by a pref, though). Right now, I'm not seeing any recent Bugzilla reports on this sort of thing happening, at least not with using the most obvious search terms.

It wasn't happening yesterday, but it is now (at least it worked for me just now, things may be different regionally). If you run the update check manually, you may have to do it twice: first to switch to the esr channel, then to get the actual update. You'll probably have to re-add some prefs to get HTML5 video working again after the undate.

That's nice of them, releasing a day early and right after I said it was gonna be tomorrow Well, at least the RC2 I tested was indeed identical to the release version. I won't have time to test the internal update procedure until tomorrow, so reports on whether it has any quirks compared to what I described in my previous post, and whether it has already switched update channels from release to esr are appreciated.