SSL decryption issue for Windows Store

[Farzana]

Hello,

After enabling SSL Decryption, we cannot download from Windows store. Getting error below.

Tried excluding hostname with Microsoft but no luck. How to fix this issue?

Thanks in advance.

[vsys_remo · Accepted solution]

I am not sure if these are still all required exceptions but it is worth a try:

[vsys_remo · Accepted solution]

I am not sure if these are still all required exceptions but it is worth a try:

[Timotheous]

fe3cr.delivery.mp.microsoft.com  is another.

[MP18]

what is the reason we need to allow all the hosts?

if we allow *.microsoft.com why does it not work then?

Curious to know the reason behind this?

[Timotheous]

We (PA support) tested *.microsoft.com in url category and a policy.  That did not work.

We then added *.microsoft.com to the ssl decryption exception list.  Still no joy.

We then added the specific fe3cr.delivery.mp.microsoft.com url.  And Success.

[vsys_remo]

@MP18 this is actually a goos question. From my side I can only say, that I did not test with *.microsoft.com as the requirement was to configure exceptions as accurate as possible.

Unfortunetely with these exact URLs there is the downside that - as we found out - they change with (not all) new microsoft versions of windows 10.

[MP18]

I have seen this behaviour with other websites where fix for us was to exempt  the source IP for decryption.

Seems *.url does not work in ssl exclusion  list.

This was not with single urls many urls and end devices were servers in data centre.

[TahirA]

Hello there,

Would you mind to tell me the fix for the same if there is any changed recently to the same url. As I am being reported continuously for the store problem as you mentioned.

I will be waiting for your reply.

thanks

[MP18]

Hi @TahirA 

We created the Decryption policy based on Source IP as exclusion list was not working on our PAN OS 8.1.9.

I do not know if PA has fixed this in newer PAN OS version.

Regards

[ericlwright]

I just ran into this same issue and came across this thread.  Instead of just adding all of the FQDNs listed in the accepted solution, I took a packet capture and found connections to both of these FQDNS were having issues :

• fe2cr.update.microsoft.com
• fe3cr.delivery.mp.microsoft.com

I added the following wildcard FQDNs, which resolved the issue:

• *.update.microsoft.com
• *.delivery.mp.microsoft.com

Of course this could change in the future, but hopefully this helps someone.