Bug: Certificate error on install and selfupdate

[panine]

Bug report Running either of

• curl -s "https://get.sdkman.io" | bash
• sdk selfupdate

results in this error curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.

The error has been there for quite a while now.

To reproduce Run the commands or simply do

curl -vkLo sdkman-cli-5.11.0+644.zip 'https://api.sdkman.io/2/broker/download/sdkman/selfupdate/5.11.0+644/Linux'

I get the following

                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* About to connect() to api.sdkman.io port 443 (#0)
*   Trying 45.55.42.78...
* Connected to api.sdkman.io (45.55.42.78) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*   subject: CN=*.sdkman.io
*   start date: May 30 00:00:00 2020 GMT
*   expire date: Apr 28 23:59:59 2022 GMT
*   common name: *.sdkman.io
*   issuer: CN=Sectigo RSA Domain Validation Secure Server CA,O=Sectigo Limited,L=Salford,ST=Greater Manchester,C=GB
> GET /2/broker/download/sdkman/selfupdate/5.11.0+644/Linux HTTP/1.1
> User-Agent: curl/7.29.0
> Host: api.sdkman.io
> Accept: */*
> 
< HTTP/1.1 302 Found
< Server: nginx/1.19.1
< Date: Fri, 02 Apr 2021 19:02:13 GMT
< Content-Length: 0
< Connection: keep-alive
< location: https://sdkman.nyc3.digitaloceanspaces.com/dist/sdkman-cli-5.11.0+644.zip
< 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host api.sdkman.io left intact
* Issue another request to this URL: 'https://sdkman.nyc3.digitaloceanspaces.com/dist/sdkman-cli-5.11.0+644.zip'
* About to connect() to sdkman.nyc3.digitaloceanspaces.com port 443 (#1)
*   Trying 52.28.60.29...
* Connected to sdkman.nyc3.digitaloceanspaces.com (52.28.60.29) port 443 (#1)
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*   subject: CN=secdns.dk
*   start date: Feb 03 04:02:23 2021 GMT
*   expire date: May 04 04:02:23 2021 GMT
*   common name: secdns.dk
*   issuer: CN=R3,O=Let's Encrypt,C=US
> GET /dist/sdkman-cli-5.11.0+644.zip HTTP/1.1
> User-Agent: curl/7.29.0
> Host: sdkman.nyc3.digitaloceanspaces.com
> Accept: */*
> 
< HTTP/1.1 302 Moved Temporarily
< Server: nginx/1.14.2
< Date: Fri, 02 Apr 2021 19:02:13 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Location: http://secdns.dk/blocked?h=sdkman.nyc3.digitaloceanspaces.com&z=nyc3.digitaloceanspaces.com&u=%2Fdist%2Fsdkman-cli-5.11.0%2B644.zip
< 
* Ignoring the response-body
{ [data not shown]
  0     0    0     1    0     0      1      0 --:--:-- --:--:-- --:--:--     1
* Connection #1 to host sdkman.nyc3.digitaloceanspaces.com left intact
* Issue another request to this URL: 'http://secdns.dk/blocked?h=sdkman.nyc3.digitaloceanspaces.com&z=nyc3.digitaloceanspaces.com&u=%2Fdist%2Fsdkman-cli-5.11.0%2B644.zip'
* About to connect() to secdns.dk port 80 (#2)
*   Trying 52.28.60.29...
* Connected to secdns.dk (52.28.60.29) port 80 (#2)
> GET /blocked?h=sdkman.nyc3.digitaloceanspaces.com&z=nyc3.digitaloceanspaces.com&u=%2Fdist%2Fsdkman-cli-5.11.0%2B644.zip HTTP/1.1
> User-Agent: curl/7.29.0
> Host: secdns.dk
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx/1.14.2
< Date: Fri, 02 Apr 2021 19:02:13 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< 
{ [data not shown]
  0     0    0  1169    0     0   1656      0 --:--:-- --:--:-- --:--:--  1656

Even curl -vLo sdkman-cli-5.11.0+644.zip http://sdkman.nyc3.digitaloceanspaces.com/dist/sdkman-cli-5.11.0+644.zipredirects to http://secdns.dk/blocked so there's just no way to get to the ZIP file.

System info VMware workstation virtual machine running CentOS 7 32GB Ram 200 GB Disk

[marc0der]

Hi @panine,

It seems like this is either caused by a corporate proxy or that your ISP is somehow intercepting the call. We will never redirect you to http://secdns.dk/blocked but always to where the binary distribution is hosted on DigitalOcean. This is where things seem to be going wrong for you:

< Location: http://secdns.dk/blocked?h=sdkman.nyc3.digitaloceanspaces.com&z=nyc3.digitaloceanspaces.com&u=%2Fdist%2Fsdkman-cli-5.11.0%2B644.zip

In future, please consider following the contributor guidelines before opening a bug report here. We are always willing and able to help you on Slack with such usage issues.

[andersaaberg]

This problem was resolved at the DNS-filter provider (Heimdal) after very useful help on slack: https://sdkman.slack.com/archives/CJTNQA94M/p1619190860042300