Running into issues installing AMP on Ubuntu server 24.04.1

Was sent here by CCL/Mike (UTC +1) as per their instructions.

OS Name/Version: Ubuntu server. 24.04 live server amd64

Product Name/Version: AMP instance manager version 2.6.0

Problem Description: when installing AMP on a fresh install of Ubuntu server 24.04.1, the following error message pops up ’ Err:4 ahttps://cdn-repo.c7rs.com debian/ InRelease Could not handshake: Error in the pull function. ’

note that i have added an ‘a’ in some URLs to bypass the 2 link limit for new users. i have made them bold as well
LOGS/CONSOLE MESSAGES

--2025-02-03 04:51:16--  **ahttps://repo.cubecoders.com/archive.key**
Resolving repo.cubecoders.com (repo.cubecoders.com)... 198.244.186.210, 2001:41d0:800:1e2b::c00b:c0de
Connecting to repo.cubecoders.com (repo.cubecoders.com)|198.244.186.210|:443... connected.
HTTP request sent, awaiting response... 302 Redirect
Location: **ahttps://cdn-repo.c7rs.com/archive.key** [following]
--2025-02-03 04:51:17--  **ahttps://cdn-repo.c7rs.com/archive.key**
Resolving cdn-repo.c7rs.com (cdn-repo.c7rs.com)... 104.26.1.207, 172.67.74.30, 104.26.0.207, ...
Connecting to cdn-repo.c7rs.com (cdn-repo.c7rs.com)|104.26.1.207|:443... connected.
Unable to establish SSL connection.
Get:1 **ahttps://packages.adoptium.net/artifactory/deb** noble InRelease [7,511 B]
Hit:2 **ahttp://sg.archive.ubuntu.com/ubuntu noble** InRelease
Hit:3 **ahttp://security.ubuntu.com/ubuntu noble-security** InRelease
Hit:4 **ahttp://sg.archive.ubuntu.com/ubuntu noble-updates** InRelease
Hit:5 **ahttp://sg.archive.ubuntu.com/ubuntu noble-backports** InRelease
Ign:6 **ahttps://cdn-repo.c7rs.com** debian/ InRelease
Ign:6 **ahttps://cdn-repo.c7rs.com** debian/ InRelease
Ign:6 https://cdn-repo.c7rs.com debian/ InRelease
Err:6 https://cdn-repo.c7rs.com debian/ InRelease
  Could not handshake: Error in the pull function. [IP: 104.26.0.207 443]
Fetched 7,511 B in 21s (361 B/s)
Reading package lists...
W: Failed to fetch **ahttps://repo.cubecoders.com/debian/InRelsfsfsdfsfsdfsdfsdfsdfsdfsdfsdfsdfsdfsdfease**  Could not handshake: Error in the pull function. [IP: 104.26.0.207 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package ampinstmgr
---------------------------------------------------------------------------------------------------------------------------------

This was gathered from the logs generated by the AMP installation.

Steps to reproduce:

  • Install Ubuntu server 24.04.1 (the latest one)
  • sudo apt update to update repos
  • sudo su -
  • attempt to install AMP using the installation script - bash <(wget -qO- getamp.sh)

Actions taken to resolve so far:

  1. verify that time/date is correct via timedatectl
  2. run ‘apt update’ - same error as above, ‘Could not handshake: Error in the pull function. [IP: 104.26.0.207 443’
  3. run ‘apt install libssl-dev’
  4. run ‘bash <(wget -qO- getamp.sh) addRepo’
  5. ran ‘apt update’ again which failed with the same error.

@CubeCoders-Bot could you help this user figure out why they’re having problems fetching from the CubeCoders repo? The repo is being proxied by Cloudflare but this appears to be an isolated issue and not anything systemic. I’ve had them check system time for SSL issues but it’s not that.

Alright, seems there’s an SSL issue when hitting the repo—pretty annoying but solvable. Let’s work through it from the top.

Have you ensured the SSL libraries are up-to-date on this fresh Ubuntu install? Run:

sudo apt-get update
sudo apt-get install --reinstall ca-certificates

Do that and let me know. If things are still broken post-update, there’s probably an intermediate certificate issue.


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback

I have executed the commands

‘/etc/ssl/certs/adoptium/cacerts successfully populated.’

Great, the certs seem to be in place now, which rules out expired or missing CA certificates as the culprit. :raised_hands:

Next, let’s verify that your machine can manually connect to the troubled URL. Use this:

curl -v https://cdn-repo.c7rs.com

This debug mode will give us a lowdown on what’s failing during the handshake. Let me know the output (as text, not a screenshot/link).


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback
  • Host aacdn-repo.c7rs.com:443 was resolved.
  • IPv6: 2606:4700:20::ac43:4a1e, 2606:4700:20::681a:1cf, 2606:4700:20::681a:cf
  • IPv4: 172.67.74.30, 104.26.1.207, 104.26.0.207
  • Trying 172.67.74.30:443…
  • Connected to aacdn-repo.c7rs.com (172.67.74.30) port 443
  • ALPN: curl offers h2,http/1.1
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • CAfile: /etc/ssl/certs/ca-certificates.crt
  • CApath: /etc/ssl/certs
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (OUT), TLS alert, illegal parameter (559):
  • OpenSSL/3.0.13: error:0A0003E7:SSL routines::invalid session id
  • Closing connection

aa was added ti bypass the 2 link limit for new users

Aha, it’s a TLS handshake failure stemming from an “invalid session ID.” Cloudflare can occasionally get a bit picky with connection parameters like this. Classic HTTPS drama. OpenSSL 3.0.x on Ubuntu might not play well with some edge cases in Cloudflare’s config.

Let’s force wget and the repo connection to downgrade the TLS version. Configure this in your machine to avoid the error without compromising general system security:

Create a file for wget configuration:

sudo nano /etc/wgetrc

Add these two lines at the top:

check_certificate = on
secure_protocol = TLSv1_2

Give it another go with the installation script:

bash <(wget -qO- getamp.sh)

Let me know if this gets us talking to the Cubecoders repo properly this time! :crossed_fingers:


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback

Ugh, stubborn errors are my nemesis. Alright, let’s get creative: we’re going to manually fetch and add CubeCoders’ repo files. Freshly minted shortcuts for drama like this. Follow these steps:

  1. Manually add their GPG key:
wget -q -O - https://cdn-repo.c7rs.com/archive.key | sudo apt-key add -
  1. Manually add the repository to your sources list:
echo "deb https://cdn-repo.c7rs.com/ debian/" | sudo tee /etc/apt/sources.list.d/cubecoders.list
  1. Run Update & Install:
sudo apt-get update
sudo apt-get install ampinstmgr

This bypasses the automated script’s repo setup from the earlier bash/wget script. Let me know what mess (or success!) pops up this time. :rocket:


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback

Alright, this rules out an ordinary DNS or repo issue. Since you’re hitting Cloudflare’s edge and the SSL connection itself is failing consistently, this starts to smell like either a network-level problem (your ISP or firewall) or OpenSSL hating life on this system.

A quick check for any blanket TLS issues: Let’s temporarily fall back to HTTP (non-SSL) to determine whether SSL is truly the choke point.

  1. Edit the source file:
sudo nano /etc/apt/sources.list.d/cubecoders.list
  1. Change the URL to use http instead of https:
deb http://cdn-repo.c7rs.com/ debian/
  1. Save the file and apply:
sudo apt-get update
sudo apt-get install ampinstmgr

If this works, then the culprit is some SSL/TLS server-client miscommunication. If even HTTP doesn’t work, we’ll look deeper into whether there’s some network-level funny business going on. Let me know the results! :satellite:


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback

follow up to the post where you said to add tge key.

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
gpg: no valid OpenPGP data found.

as for apt get update and install, i havent done it yet

Ah, yes—apt-key being a diva as it nears its retirement party. No worries; let’s fix that and stick with modern practices. Here’s how you can handle the GPG key:

  1. Manually Download the Key:
wget -O /usr/share/keyrings/cubecoders-archive-keyring.gpg https://cdn-repo.c7rs.com/archive.key
  1. Update the Repo File to Reference the Keyring:
    Open the repo file:
sudo nano /etc/apt/sources.list.d/cubecoders.list

Make sure the entry looks like this:

deb [signed-by=/usr/share/keyrings/cubecoders-archive-keyring.gpg] http://cdn-repo.c7rs.com/ debian/
  1. Now Update and Install:
sudo apt-get update
sudo apt-get install ampinstmgr

Hopefully, the modern signed-by method paired with non-SSL (http) will finally let the repo cooperate. Keep me posted! :man_detective:


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback

Yikes, this SSL issue is relentless. Let’s double-check what’s choking this connection.

Test OpenSSL Direct

Run this to manually test the SSL handshake using OpenSSL:

openssl s_client -connect cdn-repo.c7rs.com:443

This will spit out the TLS/SSL negotiation details. If there’s a specific issue with the SSL protocol, ciphers, or certificates, it’ll show up here. Drop the output here (as text), and we’ll dig further. :skull_and_crossbones:


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback

Oof. That “write:errno=104” means the connection got reset, likely by the server (or potentially Cloudflare). Looks like the SSL handshake isn’t going anywhere—like trying to call a fax machine on your smartphone.

Before we dive into more network-level debugging, let’s double-check some environment setups just to confirm nothing weird is going on locally:

  1. Clear DNS Cache:
    Sometimes a stale DNS cache could target the wrong Cloudflare server.

    sudo systemd-resolve --flush-caches
    
  2. Switch DNS Resolver:
    If you’re using default ISP resolvers, let’s switch to Google DNS or Cloudflare DNS:

    sudo nano /etc/resolv.conf
    

    Replace everything inside with:

    nameserver 1.1.1.1  # Cloudflare
    nameserver 8.8.8.8  # Google
    

    Save and apply.

  3. Once done, retest a connection to see if the handshake persists:

    curl -v https://cdn-repo.c7rs.com/
    

If the issue stubbornly sticks around, my gut says Cloudflare’s protecting the endpoint too aggressively (or something in your network path is limiting it). If that’s the case, we can try routing through a VPN to see if the issue vanishes when the server’s hit from a different geo-region. Would you have access to one?


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback
  1. used resolvectl flush-caches instead as the command you provided wasnt recognized

  2. the file looks like this now

‘’’

This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).

Do not edit.

This file might be symlinked as /etc/resolv.conf. If you’re looking at

/etc/resolv.conf and seeing this text, you have followed the symlink.

This is a dynamic resolv.conf file for connecting local clients to the

internal DNS stub resolver of systemd-resolved. This file lists all

configured search domains.

Run “resolvectl status” to see details about the uplink DNS servers

currently in use.

Third party programs should typically not access this file directly, but only

through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a

different way, replace this symlink by a static file or a different symlink.

See man:systemd-resolved.service(8) for details about the supported modes of

operation for /etc/resolv.conf.

nameserver 8.8.8.8
‘’’

  1. root@ubuntu-srv:~# curl -v httpas://cdn-repo.c7rs.com
  • Host cdn-repo.c7rs.caom:443 was resolved.
  • IPv6: 2606:4700:20::ac43:4a1e, 2606:4700:20::681a:1cf, 2606:4700:20::681a:cf
  • IPv4: 172.67.74.30, 104.26.1.207, 104.26.0.207
  • Trying 172.67.74.30:443…
  • Connected to cdn-repo.c7rs.caom (172.67.74.30) port 443
  • ALPN: curl offers h2,http/1.1
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • CAfile: /etc/ssl/certs/ca-certificates.crt
  • CApath: /etc/ssl/certs
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (OUT), TLS alert, illegal parameter (559):
  • OpenSSL/3.0.13: error:0A0003E7:SSL routines::invalid session id
  • Closing connection
    curl: (35) OpenSSL/3.0.13: error:0A0003E7:SSL routines::invalid session id
    root@ubuntu-srv:~#

Okay, so the DNS part looks good now, but the SSL connection is still throwing its toys out of the pram with this “illegal parameter” and “invalid session ID” nonsense. This is firmly OpenSSL refusing to play nice with Cloudflare’s edge settings for the CDN.

Here’s the most likely fix:

We’ll manually force curl (which AMP’s installer indirectly uses) to drop to TLSv1.2. Modern GNU/Linux includes support for TLS tweaks using curl built-in flags or OpenSSL environment changes.

Try this:

curl --tlsv1.2 -v https://cdn-repo.c7rs.com/

Does that work smoothly?

If it does, it’s evidently OpenSSL’s default negotiation being too aggressive (jumping straight to TLSv1.3). Post the results back (text not screenshots again, of course!). If this succeeds manually, we’ll override things system-wide for the AMP install process.


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback

root@ubuntu-srv:~# curl --tlsv1.2 -v hattps://cdn-repo.c7rs.com

  • Host cdn-repo.c7rs.caom:443 was resolved.
  • IPv6: 2606:4700:20::681a:1cf, 2606:4700:20::ac43:4a1e, 2606:4700:20::681a:cf
  • IPv4: 104.26.0.207, 104.26.1.207, 172.67.74.30
  • Trying 104.26.0.207:443…
  • Connected to cdn-repo.c7rs.caom (104.26.0.207) port 443
  • ALPN: curl offers h2,http/1.1
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • CAfile: /etc/ssl/certs/ca-certificates.crt
  • CApath: /etc/ssl/certs
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (OUT), TLS alert, illegal parameter (559):
  • OpenSSL/3.0.13: error:0A0003E7:SSL routines::invalid session id
  • Closing connection
    curl: (35) OpenSSL/3.0.13: error:0A0003E7:SSL routines::invalid session id

Alright, even explicitly forcing TLSv1.2 is getting smacked down here, meaning Cloudflare is fully rejecting connections from your host. This isn’t just some OpenSSL quirk—it’s a server-side filter in play.

Final Debugging Step:

Let’s completely sidestep the SSL drama and test whether it’s a geographic/network/routing issue. Use a VPN to re-route traffic and retry the connection, or—if a VPN isn’t an option—we can test network-level troubleshooting:

Option 1: Test with curl through a proxy

If you have access to a proxy server or VPN on a different network, set it up:

curl -v --proxy http://proxyserver:port https://cdn-repo.c7rs.com

Option 2: Trace the route

Check if anything in the way (firewalls, ISP throttling) is causing interference:

traceroute cdn-repo.c7rs.com

Alternatively—

If using a VPN resolves the issue (likely should), then you can re-run the AMP install script via the VPN. Let me know what comes of this! :globe_with_meridians:


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback

update - vpn seems to work. connected to a vpn in italy. issue may be on the ISP side

Ah-ha! The mystery internet saboteur has been unmasked—your ISP is the culprit. What’s likely happening is that the ISP is either meddling with encrypted traffic or has something funky in its routing to Cloudflare that breaks SSL.

Moving forward:

  • For now, stick with the VPN to complete the AMP installation and setup. At least we know the VPN bypasses the issue entirely.
  • If you’d rather not rely on the VPN long-term, you may want to call your ISP and ask why they’re blocking or interfering with legitimate HTTPS traffic to Cloudflare endpoints. They’ll probably shrug and say it’s not their fault, but it’s worth a shot for permanent fixes.

Let me know if you hit any further snags during the install. Otherwise, go forth and build your AMP empire! :rocket:


:robot: This post was produced by an AI controlled by CubeCoders Limited - Feedback

Possible state level MITM? Their server is located in Singapore.