[FOLLOW UP ON ITEM] New canisters will only be accessible through the icp0.io domain. Existing canisters will be accessible both through ic0.app and icp0.io

Developers
41

Thanks for getting back ^^

Well it’s bizarre really. I’ve connected to both eduroam and my local Uni wifi and the error persists. However my local wifi clearly has some sort of firewall in place whereas I am able to access any content on eduroam.

Here is the output you requested.

*   Trying 145.40.94.174:443...
* Connected to 5perb-kiaaa-aaaag-abkaq-cai.icp0.io (145.40.94.174) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=boundary.dfinity.network
*  start date: Apr 20 17:18:48 2023 GMT
*  expire date: Jul 19 17:18:47 2023 GMT
*  subjectAltName: host "5perb-kiaaa-aaaag-abkaq-cai.icp0.io" matched cert's "*.icp0.io"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fe329010a00)
> GET / HTTP/2
> Host: 5perb-kiaaa-aaaag-abkaq-cai.icp0.io
> user-agent: curl/7.79.1
> accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 404 
< server: nginx/1.21.3
< date: Tue, 25 Apr 2023 19:08:27 GMT
< content-length: 79
< access-control-allow-origin: *
< access-control-allow-credentials: true
< access-control-allow-headers: DNT,User-Agent,X-Requested-With,If-None-Match,If-Modified-Since,Cache-Control,Content-Type,Range,Cookie
< access-control-expose-headers: Accept-Ranges,Content-Length,Content-Range
< access-control-max-age: 600
< 
* Connection #0 to host 5perb-kiaaa-aaaag-abkaq-cai.icp0.io left intact
IC0302: Canister 5perb-kiaaa-aaaag-abkaq-cai has no query method 'http_request'```


 curl -sLvv https://5perb-kiaaa-aaaag-abkaq-cai.ic0.app
*   Trying 193.63.72.83:443...
* Connected to 5perb-kiaaa-aaaag-abkaq-cai.ic0.app (193.63.72.83) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (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 change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: serialNumber=05747339; jurisdictionCountryName=GB; businessCategory=Private Organization; C=GB; ST=Bristol, City of; O=Jisc; CN=landing.soc.ja.net
*  start date: Nov 16 00:00:00 2022 GMT
*  expire date: Nov 16 23:59:59 2023 GMT
*  subjectAltName does not match 5perb-kiaaa-aaaag-abkaq-cai.ic0.app
* SSL: no alternative certificate subject name matches target host name '5perb-kiaaa-aaaag-abkaq-cai.ic0.app'
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
1 Like
42

Yes indeed, it looks like there is some filtering in place. When you look at the certificate name in your second curl, you can see that there was something injected:

CN=landing.soc.ja.net

Looks like your university is using the “Janet Network resolver” service, which blocks the request:

Janet Network Resolver helps to protect your organisation by preventing your devices and network from accessing known malicious or compromised websites. It’s free to all Jisc member colleges, universities and research institutions and Janet connected customer organisations who have actively registered for the service.

On their landing page, they specify an email where you can report wrong restrictions. You can do that if you want to:

If you think a request to a website is wrongfully restricted, write an email to irt@jisc.ac.uk

In any case, it would be interesting, if you could also check the following canisters to understand whether specific canisters are blocked or all and under which domains (ic0.app and icp0.io).

https://qoctq-giaaa-aaaaa-aaaea-cai.ic0.app/
https://qoctq-giaaa-aaaaa-aaaea-cai.icp0.io/
https://rdmx6-jaaaa-aaaaa-aaadq-cai.ic0.app/
https://rdmx6-jaaaa-aaaaa-aaadq-cai.icp0.io/
43

Our team has reached out to JISC and they confirmed that ic0.app has been removed from their filter. @LowFreeKey could you please try again. Thanks :slight_smile:

4 Likes
44

yay! Hope that improves for all the folks accepted. Thank you @LowFreeKey for pointing it out

2 Likes
45

Working! Nicely done ^^

2 Likes