TLS error access denied when trying to pull images from cdn.mscr.io endpoint

[MRavenscroft]

Hi,

We've been using the official microsoft images for our project that we are converting to use containers, and they were working a few months back. An example image that we are using is "mcr.microsoft.com/dotnet/core/sdk:3.1". However, some of our developers started running into a problem (I believe it was in Februrary initially) where we were getting access denied when trying to pull. when we try to pull the hello-world image from the "cdn.mscr.io" endpoint in https://github.com/microsoft/containerregistry/blob/master/client-firewall-rules.md, we get the same access denied error:

error pulling image configuration: Get https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/09/095f049ec3a4c206f052648375b06599ce9d4332283bfd44ee99180c08df80f4/data?P1=1584975330&P2=1&P3=1&P4=jHPUhkNwRchm0jNoB4UjwQUNIAXMiZOtfVlvnec6bUs%3D&se=2020-03-23T14%3A55%3A30Z&sig=38Yi7vguA9F9jeX5kiuYxy4yIARQ50E0byn%2BakcA33w%3D&sp=r&sr=b&sv=2016-05-31&regid=791e7ca5469f40b1b54c65b23e5dbde2: remote error: tls: access denied

When the endpoints for the images were moved to the ".data.mcr.microsoft.com" the pulling started to work for us, but now that the change was rolled back we are now getting the access denied error again.

Other things to note:

• We are using Linux container in docker-desktop
• A couple of developers machines can successfully pull the images, but they have the same setup, and corporate firewall/antivirus etc. installations.

We've tried to identify whats causing it, but haven't had much success.

• We've checked our firewall settings and they are the same across developers,
• We've tried fresh installs of docker desktop as well.
• We've tried disconnecting from the corporate network and we still get the same error.
• Resetting SSL certificates and doing a direct curl to the endpoint rather than going through docker provides the same error too.

Is there anything else we could try (or a setup step we've missed?), or could there be an issue with the endpoint?

Thanks,
Mike

[toddysm]

@MRavenscroft Would you mind checking whether you are running behind a proxy? If so, can you compare the proxy configurations for a working and a non-working machine?

[MRavenscroft]

I've checked the proxy settings and as far as i can tell i'm not behind one - my proxy options are turned off and i'm disconnected from our corporate VPN. Online proxy checks also cannot detect anything.

[toddysm]

@MRavenscroft apologies for the delay. Just wanted to check with you whether you are still experiencing the issue?

[MRavenscroft]

No worries. Yep, we are still getting the issue same issue when we try to pull from there. We are working around it for now by building and hosting our own base images with the same contents as the official ones, but we'd much prefer to be able to use the official images.

[toddysm]

@MRavenscroft We are looking at this. Will keep you posted

[jhkimnew]

@MRavenscroft, Would you troubleshoot with curl or chrome browser to narrow down (or troubleshoot) the issue again?

Here is how to do that.

Each docker image layer can be downloaded with the following URL form.

"https://mcr.microsoft.com/v2//blobs/"

Supposing the repository path is "dotnet/core/sdk" and the layer's sha value is sha256:90fe46dd819953eb995f9cc9c326130abe9dd0b3993a998e12c01d0218a0b831, you can get the docker image layer with the below URL with any web browser such as Chrome.

https://mcr.microsoft.com/v2/dotnet/core/sdk/blobs/sha256:90fe46dd819953eb995f9cc9c326130abe9dd0b3993a998e12c01d0218a0b831.

When you browse the URL, you will notice that it is redirected to a new URL which uses the "cdn.mscr.io" CDN end point that you have reported with the error message.

Please notice that the redirected URL will contain the same sha value without "sha256:" prefix.
That means you can get the sha value directly from the error message supposing you know the repository path.

If you still reproduce the issue with the same access denied error, please try the same url on other machines where the url works returning image data file successfully. And then, you might want to compare the two machine to check how the redirected URL pah is made. FYI, if the Azure region where the client is placed is different, the CDN endpoint will use a different one for each other. Ex. mcrneu0.cdn.mscr.io or mcrwcus0.cdn.mscr.io and etc.

If you still can't figure out any hint or no difference between repro/non repro machines, please share the exact error message that you obtained from the brower with the url and the two URL addresses, one in the form of "https://mcr.microsoft.com/v2//blobs/" and the redirected URL.

[jhkimnew]

@MRavenscroft
I happened to find the sha value of the error message you reported here can be made from the below image layer URL. Please notice that the repository is "mcr/hello-world".

https://mcr.microsoft.com/v2/mcr/hello-world/blobs/sha256:095f049ec3a4c206f052648375b06599ce9d4332283bfd44ee99180c08df80f4

Can you confirm if the above URL matches the URL that you used when you received the error message?

Anyway, I confirmed that I can download the image layer with "curl -L" as the below screenshot and confirmed the CDN endpoint is matched as well with "curl" without "-L".
FYI, I had to use 13.69.227.83 for mcr.microsoft.com host name in /etc/hosts in order to simulate if I am in the region for mcrneu0.cdn.mscr.io CDN end point.

jhkim@jhkimlinux2:~$ cat /etc/hosts
13.69.227.83 mcr.microsoft.com

jhkim@jhkimlinux2:~$ curl -L -o output https://mcr.microsoft.com/v2/mcr/hello-world/blobs/sha256:095f049ec3a4c206f052648375b06599ce9d4332283bfd44ee99180c08df80f4
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   471  100   471    0     0   1524      0 --:--:-- --:--:-- --:--:--  1519
100  1718  100  1718    0     0   2701      0 --:--:-- --:--:-- --:--:--  2701

jhkim@jhkimlinux2:~$ ls -l
-rw-rw-r-- 1 jhkim jhkim 1718 Apr 28 23:30 output

jhkim@jhkimlinux2:~$ curl https://mcr.microsoft.com/v2/mcr/hello-world/blobs/sha256:095f049ec3a4c206f052648375b06599ce9d4332283bfd44ee99180c08df80f4
<a href="https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/09/095f049ec3a4c206f052648375b06599ce9d4332283bfd44ee99180c08df80f4/data?P1=1588117821&amp;P2=1&amp;P3=1&amp;P4=1L5MvOi05WxQga2YJRl5KiN6vhV%2FTuS2rgtSYUxnu14%3D&amp;se=2020-04-28T23%3A50%3A21Z&amp;sig=E8NXEMgAHPZ%2BVD%2FgCt2CJkr3O58sXSuizXhD8GiVdwI%3D&amp;sp=r&amp;sr=b&amp;sv=2016-05-31&amp;regid=791e7ca5469f40b1b54c65b23e5dbde2">Temporary Redirect</a>.

[MRavenscroft]

Thanks,

I've done some of that troubleshooting, The error i get when i try to pull for example the dotnet core SDK image is:

docker pull mcr.microsoft.com/dotnet/core/sdk:3.1
3.1: Pulling from dotnet/core/sdk
90fe46dd8199: Pulling fs layer                                                                                          
35a4f1977689: Pulling fs layer                                                                                          
bbc37f14aded: Pulling fs layer                                                                                         
74e27dc593d4: Waiting                                                                                                   
caa6ad693f93: Waiting                                                                                                   
aae86a99db0a: Waiting                                                                                                   
95f813d5736b: Waiting                                                                                                   

error pulling image configuration: Get https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/4a/4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a/data?P1=1588149727&P2=1&P3=1&P4=d1TXcHi4Kb8Pj2IdRTd4%2Fy4uIsp0oRFeX8YPNMgDoa4%3D&se=2020-04-29T08%3A42%3A07Z&sig=CRKRAPGEzi2vtJoQ06CNEo1baE4JAMloahN3vMamhmM%3D&sp=r&sr=b&sv=2016-05-31&regid=791e7ca5469f40b1b54c65b23e5dbde2: remote error: tls: access denied

And from that, i built the url with the sha: https://mcr.microsoft.com/v2/dotnet/core/sdk/blobs/sha256:4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a

Then, when i navigate or curl to that i get an SSL error saying i cannot connect to it

The redirected URL that it shows is:
https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/4a/4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a/data?P1=1588149422&P2=1&P3=1&P4=UJKKCa8Aj5LkMYJICETIZlyBzTrLk%2Fn3MfpELB887a0%3D&se=2020-04-29T08%3A37%3A02Z&sig=yh0vaPSYA3roczz9eCN6nf2Ao8LiyQKDpP5uUDFEung%3D&sp=r&sr=b&sv=2016-05-31&regid=791e7ca5469f40b1b54c65b23e5dbde2

When the member of the team who can connect to it tries either of those URLs (The original one with the sha, and the redirected one) and curling to it, it connects correctly for him, giving him a file to download and connection.

Hope that helps. Not sure what the difference could be, as we have the same setup

[jhkimnew]

@MRavenscroft Did you check the certificate for the redirected URL? I sent the redirected URL from my machine. Even though I received "ERROR 403: Time-Limited URL validation", which is expected, I was able to see the certificate. It shows "*.cdn.mscr.io" for "Issued to:" as the below screenshot. Can you compare with this? If you received a different certificate for some reasons, that might be the reason of the SSL error.

[MRavenscroft]

ah, that could be promising. It does look like i'm getting a different certificate to you when i get to the page with the error:

[jhkimnew]

@MRavenscroft Would you execute the below two commands and send the result?
This is to get more detailed information about the SSL error. I also wanted to verify what IP address and what certificate is picked up from your machine for the original request and the redirected URL with the request.

1. nslookup mcrneu0.cdn.mscr.io

2. curl --verbose -L https://mcr.microsoft.com/v2/dotnet/core/sdk/blobs/sha256:4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a

[MRavenscroft]

This is what i get from the nslookup (when not connected to the corporate VPN)

Server:  cache1.service.virginmedia.net
Address:  194.168.4.100

Non-authoritative answer:
Name:    mcrneu0.cdn.mscr.io.MII.COM
Address:  92.242.132.24

And this is what i get from the curl:

*   Trying 13.69.227.83...
* TCP_NODELAY set
* Connected to mcr.microsoft.com (13.69.227.83) port 443 (#0)
* schannel: SSL/TLS connection with mcr.microsoft.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 182 bytes...
* schannel: sent initial handshake data: sent 182 bytes
* schannel: SSL/TLS connection with mcr.microsoft.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with mcr.microsoft.com port 443 (step 2/3)
* schannel: encrypted data got 4000
* schannel: encrypted data buffer: offset 4000 length 4096
* schannel: sending next handshake data: sending 126 bytes...
* schannel: SSL/TLS connection with mcr.microsoft.com port 443 (step 2/3)
* schannel: encrypted data got 258
* schannel: encrypted data buffer: offset 258 length 4096
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with mcr.microsoft.com port 443 (step 3/3)
* schannel: stored credential handle in session cache
> GET /v2/dotnet/core/sdk/blobs/sha256:4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a HTTP/1.1
> Host: mcr.microsoft.com
> User-Agent: curl/7.55.1
> Accept: */*
>
* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 1558
* schannel: encrypted data buffer: offset 1558 length 103424
* schannel: decrypted data length: 1529
* schannel: decrypted data added: 1529
* schannel: decrypted data cached: offset 1529 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 1529 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 1529
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 307 Temporary Redirect
< Server: openresty
< Date: Fri, 01 May 2020 06:57:10 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 469
< Connection: keep-alive
< Access-Control-Expose-Headers: Docker-Content-Digest
< Access-Control-Expose-Headers: WWW-Authenticate
< Access-Control-Expose-Headers: Link
< Access-Control-Expose-Headers: X-Ms-Correlation-Request-Id
< Docker-Distribution-Api-Version: registry/2.0
< Location: https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/4a/4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a/data?P1=1588317385&P2=1&P3=1&P4=eA4ogIrrkRj8DxD8DTAJ4M1w1FUTMpx%2FqPf7QwDcW9Q%3D&se=2020-05-01T07%3A16%3A25Z&sig=kkh%2F4Adtpa5p24BxVDoqfPm0HxI8qT8HCOsuQySRq3g%3D&sp=r&sr=b&sv=2016-05-31&regid=791e7ca5469f40b1b54c65b23e5dbde2
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-Content-Type-Options: nosniff
< X-Ms-Correlation-Request-Id: 064a3b1b-d1a0-4d26-b1ee-f3555232fa9e
< Strict-Transport-Security: max-age=31536000; includeSubDomains
<
* Ignoring the response-body
* Connection #0 to host mcr.microsoft.com left intact
* Issue another request to this URL: 'https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/4a/4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a/data?P1=1588317385&P2=1&P3=1&P4=eA4ogIrrkRj8DxD8DTAJ4M1w1FUTMpx%2FqPf7QwDcW9Q%3D&se=2020-05-01T07%3A16%3A25Z&sig=kkh%2F4Adtpa5p24BxVDoqfPm0HxI8qT8HCOsuQySRq3g%3D&sp=r&sr=b&sv=2016-05-31&regid=791e7ca5469f40b1b54c65b23e5dbde2'
*   Trying 204.79.197.219...
* TCP_NODELAY set
* Connected to mcrneu0.cdn.mscr.io (204.79.197.219) port 443 (#1)
* schannel: SSL/TLS connection with mcrneu0.cdn.mscr.io port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 184 bytes...
* schannel: sent initial handshake data: sent 184 bytes
* schannel: SSL/TLS connection with mcrneu0.cdn.mscr.io port 443 (step 2/3)
* schannel: encrypted data got 7
* schannel: encrypted data buffer: offset 7 length 4096
* schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.
* Closing connection 1
* schannel: shutting down SSL/TLS connection with mcrneu0.cdn.mscr.io port 443
* schannel: clear security context handle
curl: (35) schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log.

[jhkimnew]

@MRavenscroft
According to the returned result, the more detail is available in the Windows System event log. Can you check if the error event(s) show any hint for further troubleshooting?

FYI, I am not sure but it seems that your machine has some issue on schannel module. According to the log you sent, it received only 7 byte out of 4096 byte and InitializeSecurityContext seems to be failed because it did not receive the required data for some reasons.

* schannel: SSL/TLS connection with mcrneu0.cdn.mscr.io port 443 (step 2/3)
* schannel: encrypted data got 7
* schannel: encrypted data buffer: offset 7 length 4096
* schannel: next InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) 
...

BTW, do you have any Linux (Ubuntu) shows the same problem? If so, would you execute the same command on Linux (such as Ubuntu) machine? Considering the fact that the Linux version curl can show more detailed information of the failure.

[jhkimnew]

Hi @MRavenscroft, do you have any update?

[MRavenscroft]

Hi @jhkimnew ,

I had a look through the windows event log but couldnt find anything in there. I don't have a linux machine available, but did run a different installation of curl which has given a different result (I'm not sure whether the one i was running before came with Windows by default, or with my Git installation as i believe i read that git has curl built-in).
The latest curl result which has some information of the certificate is:

*   Trying 13.69.227.83:443...
* Connected to mcr.microsoft.com (13.69.227.83) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: C:\curl\bin\curl-ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=mcr.microsoft.com
*  start date: Feb 19 00:14:10 2020 GMT
*  expire date: Feb 19 00:14:10 2022 GMT
*  subjectAltName: host "mcr.microsoft.com" matched cert's "mcr.microsoft.com"
*  issuer: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; OU=Microsoft IT; CN=Microsoft IT TLS CA 2
*  SSL certificate verify ok.
> GET /v2/dotnet/core/sdk/blobs/sha256:4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a HTTP/1.1
> Host: mcr.microsoft.com
> User-Agent: curl/7.70.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 307 Temporary Redirect
< Server: openresty
< Date: Mon, 11 May 2020 07:24:05 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 475
< Connection: keep-alive
< Access-Control-Expose-Headers: Docker-Content-Digest
< Access-Control-Expose-Headers: WWW-Authenticate
< Access-Control-Expose-Headers: Link
< Access-Control-Expose-Headers: X-Ms-Correlation-Request-Id
< Docker-Distribution-Api-Version: registry/2.0
< Location: https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/4a/4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a/data?P1=1589182859&P2=1&P3=1&P4=bknHTcI6PhxIx%2F1yxVN%2FEMya2ANgZFHGmzhTP4jdDP0%3D&se=2020-05-11T07%3A40%3A59Z&sig=JzvI%2Bv4WWlRinvntMBRcMMqY9tL%2FgGeXDeDSs%2B8tEx0%3D&sp=r&sr=b&sv=2016-05-31&regid=791e7ca5469f40b1b54c65b23e5dbde2
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-Content-Type-Options: nosniff
< X-Ms-Correlation-Request-Id: 2da974cd-3e8a-4c1c-82b8-4428cf613c22
< Strict-Transport-Security: max-age=31536000; includeSubDomains
<
<a href="https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/4a/4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a/data?P1=1589182859&amp;P2=1&amp;P3=1&amp;P4=bknHTcI6PhxIx%2F1yxVN%2FEMya2ANgZFHGmzhTP4jdDP0%3D&amp;se=2020-05-11T07%3A40%3A59Z&amp;sig=JzvI%2Bv4WWlRinvntMBRcMMqY9tL%2FgGeXDeDSs%2B8tEx0%3D&amp;sp=r&amp;sr=b&amp;sv=2016-05-31&amp;regid=791e7ca5469f40b1b54c65b23e5dbde2">Temporary Redirect</a>.

* Connection #0 to host mcr.microsoft.com left intact

In case its useful, if i do the same curl on the redirected URL that is throwing the access denied when trying to do the docker pull, i get:

*   Trying 204.79.197.219:443...
* Connected to mcrneu0.cdn.mscr.io (204.79.197.219) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: C:\curl\bin\curl-ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, access denied (561):
* error:14094419:SSL routines:ssl3_read_bytes:tlsv1 alert access denied
* Closing connection 0

[jhkimnew]

Hi @MRavenscroft,

Didn't you use "-L" parameter when you execute curl? If you use "-L", the curl will follow redirects and you don't need to run it for the redirected URL.

If you did not use the "-L" parameter, would you try again with "-L" and check if you still get the same access denied error? BTW, please give the full log and the command line you used so that I can understand what you tried and how to analyze the log.

C:\> curl --help
Usage: curl [options...] <url>
...
 -L, --location      Follow redirects

Thanks,
Jeong Hwan Kim

[MRavenscroft]

Hi @jhkimnew

Sure thing, I've just double-checked, and the initial command I'd ran was the same one from above. The full log, including the command is:

C:\curl\bin>curl --verbose -L https://mcr.microsoft.com/v2/dotnet/core/sdk/blobs/sha256:4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a
*   Trying 13.69.227.83:443...
* Connected to mcr.microsoft.com (13.69.227.83) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: C:\curl\bin\curl-ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=mcr.microsoft.com
*  start date: Feb 19 00:14:10 2020 GMT
*  expire date: Feb 19 00:14:10 2022 GMT
*  subjectAltName: host "mcr.microsoft.com" matched cert's "mcr.microsoft.com"
*  issuer: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; OU=Microsoft IT; CN=Microsoft IT TLS CA 2
*  SSL certificate verify ok.
> GET /v2/dotnet/core/sdk/blobs/sha256:4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a HTTP/1.1
> Host: mcr.microsoft.com
> User-Agent: curl/7.70.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 307 Temporary Redirect
< Server: openresty
< Date: Wed, 13 May 2020 22:12:44 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 469
< Connection: keep-alive
< Access-Control-Expose-Headers: Docker-Content-Digest
< Access-Control-Expose-Headers: WWW-Authenticate
< Access-Control-Expose-Headers: Link
< Access-Control-Expose-Headers: X-Ms-Correlation-Request-Id
< Docker-Distribution-Api-Version: registry/2.0
< Location: https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/4a/4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a/data?P1=1589409164&P2=1&P3=1&P4=6jQL8BBep%2FTahaJUjrMN0cPYrJ%2BXK9nPqvGea10JCAM%3D&se=2020-05-13T22%3A32%3A44Z&sig=z5mj31vUYTh7UGEWfucUzCbjIbdpu3z0vZZFBiLfcj8%3D&sp=r&sr=b&sv=2016-05-31&regid=791e7ca5469f40b1b54c65b23e5dbde2
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< X-Content-Type-Options: nosniff
< X-Ms-Correlation-Request-Id: 830b03d0-0400-42cd-bf3b-d9488ac31f39
< Strict-Transport-Security: max-age=31536000; includeSubDomains
<
* Ignoring the response-body
* Connection #0 to host mcr.microsoft.com left intact
* Issue another request to this URL: 'https://mcrneu0.cdn.mscr.io/791e7ca5469f40b1b54c65b23e5dbde2-qgy0s4qedy//docker/registry/v2/blobs/sha256/4a/4aa6a74611ff353e9fd7ab05a3f837bfecb894592d3ae921bad52008def6fd2a/data?P1=1589409164&P2=1&P3=1&P4=6jQL8BBep%2FTahaJUjrMN0cPYrJ%2BXK9nPqvGea10JCAM%3D&se=2020-05-13T22%3A32%3A44Z&sig=z5mj31vUYTh7UGEWfucUzCbjIbdpu3z0vZZFBiLfcj8%3D&sp=r&sr=b&sv=2016-05-31&regid=791e7ca5469f40b1b54c65b23e5dbde2'
*   Trying 204.79.197.219:443...
* Connected to mcrneu0.cdn.mscr.io (204.79.197.219) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: C:\curl\bin\curl-ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, access denied (561):
* error:14094419:SSL routines:ssl3_read_bytes:tlsv1 alert access denied
* Closing connection 1
curl: (35) error:14094419:SSL routines:ssl3_read_bytes:tlsv1 alert access denied

C:\curl\bin>

[jhkimnew]

Hi @MRavenscroft Honestly, I am not export on TLS issue. However, I think this is not a problem in MCR server side.

MCR web server is mirrored in multiple regions. So, can you try the different region server instead of using your geographical region server? This is to confirm if or not you see the same issue with the different server.

For example, in my region (westus), I can can the IP address of my region server with running "nslookup rpm0422wus.westus.cloudapp.azure.com".

So, you can try use the westus instead of your region server.
Here is how to do that.

1. Run nslookup rpm0422wus.westus.cloudapp.azure.com to get the IP address of the hostname for the westus region server.
2. Open %windir%\system32\drivers\etc\hosts and add this line. Replace with the ip address of the westus region server.

mcr.microsoft.com

3. Save the file and try the curl command again.

FYI, in case you curious how to find the specific host name (rpm0422wus.westus.cloudapp.azure.com), the answer is that I used "nslookup mcr.microsoft.com" to find the host name as the following screenshot shows.

C:\> nslookup mcr.microsoft.com
Server:  UnKnown
Address:  2001:4898::1050:1050

Non-authoritative answer:
Name:    rpm0422wus.westus.cloudapp.azure.com
Address:  40.112.242.159
Aliases:  mcr.microsoft.com
          global.fe.mscr.io
          mcr-global.trafficmanager.net

[jhkimnew]

@MRavenscroft I am closing this issue considering this issue seems to happen only from your machine or a specific networks issue.