SSL/HTTPS completely broken for my app - certificate provisioning issue

[agrberg]

Outside of the browser, my Koyeb app json-agrberg.koyeb.app is completely inaccessible via HTTPS, while HTTP redirects to a security warning page. This appears to be an SSL certificate provisioning failure on Koyeb’s infrastructure.

The application is running and accessible via HTTPS in both the latest versions of Chrome and Firefox. However it cannot be accessed outside of the browser (e.g. curl, wget, etc.).

Here is what I’ve discovered so far

• HTTP works but redirects to safebrowse.io warning
• HTTPS fails with SSL handshake errors from all clients
• Direct IP connections to Cloudflare also fail

I found a similar post at My app's url with "https" is not working but I do not have dots in my name.

For reference I am on the latest version of macOS 15.6.1 with curl 8.15.0 (OpenSSL 3.5.2)

Technical Evidence

DNS Resolution (working correctly):
json-agrberg.koyeb.app. 300 IN CNAME prod-glb.koyeb.app.cdn.cloudflare.net.
prod-glb.koyeb.app.cdn.cloudflare.net. 300 IN A 104.20.31.27
prod-glb.koyeb.app.cdn.cloudflare.net. 300 IN A 172.66.172.174

HTTPS Failure (multiple clients):
$ curl -v https://json-agrberg.koyeb.app

• TLS connect error: error:0A00010B:SSL routines::wrong version number
  curl: (35) TLS connect error: error:0A00010B:SSL routines::wrong version number

$ openssl s_client -connect json-agrberg.koyeb.app:443
C02045EF01000000:error:0A0000C6:SSL routines:tls_get_more_records:packet length too long
C02045EF01000000:error:0A000139:SSL routines::record layer failure

Direct IP Test (confirms server-side issue):
$ openssl s_client -connect 104.20.31.27:443 -servername json-agrberg.koyeb.app
C02045EF01000000:error:0A0000C6:SSL routines:tls_get_more_records:packet length too long
C02045EF01000000:error:0A000139:SSL routines::record layer failure

Root Cause:
The “packet length too long” error indicates Cloudflare is not serving a valid SSL certificate for my subdomain. Instead of SSL/TLS data, it’s returning non-SSL content, causing all SSL clients to fail.

What I’ve Tried:

• Multiple curl versions (system LibreSSL and Homebrew OpenSSL)
• Different networks and DNS servers
• Direct IP connections with Host header
• Various TLS versions and cipher specifications

Questions:

1. Is there a known issue with SSL certificate provisioning?
2. How can I check the certificate status in my dashboard?
3. Should I redeploy the app to trigger certificate re-provisioning?
4. Is this related to any recent infrastructure changes?

This appears to be a server-side SSL configuration issue so any guidance would be appreciated!

[yann]

I’m able to properly access this app, did you manage to fix it?

[agrberg]

Did you use a web browser or a tool like curl? I went back an emphasized in the original post that while it is accessible via the browser, it is not accessible via other tools.

[bastien]

I’ve tested with curl and it’s working fine from here (laptop, or a random koyeb service).

root@8b048ce9:/# curl -4 -v https://json-agrberg.koyeb.app
* Host json-agrberg.koyeb.app:443 was resolved.
* IPv6: (none)
* IPv4: 172.66.172.174, 104.20.31.27
*   Trying 172.66.172.174:443...
* Connected to json-agrberg.koyeb.app (172.66.172.174) 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 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.koyeb.app
*  start date: Sep  4 18:45:41 2025 GMT
*  expire date: Dec  3 18:45:40 2025 GMT
*  subjectAltName: host "json-agrberg.koyeb.app" matched cert's "*.koyeb.app"
*  issuer: C=US; O=Let's Encrypt; CN=E7
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://json-agrberg.koyeb.app/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: json-agrberg.koyeb.app]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: json-agrberg.koyeb.app
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200 

openssl also returns proper certificate (openssl s_client -connect json-agrberg.koyeb.app:443)

depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=E7
verify return:1
depth=0 CN=*.koyeb.app
verify return:1
---
Certificate chain
 0 s:CN=*.koyeb.app
   i:C=US, O=Let's Encrypt, CN=E7
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA384
   v:NotBefore: Sep  4 18:45:41 2025 GMT; NotAfter: Dec  3 18:45:40 2025 GMT
 1 s:C=US, O=Let's Encrypt, CN=E7
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
   a:PKEY: EC, (secp384r1); sigalg: sha256WithRSAEncryption
   v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
...

For this domain, the certificate is a wildcard, so it’s only provisioned once in a while.

I would say it’s most likely a client-side certificate pack issue, or a local network issue, like something intercepting your traffic for some reason.

Do you also have issues accessing using curl and http only?

[agrberg]

tl;dr solution:

Your ISP might be hijacking your request. To see if this is the case try a curl to the http endpoint. In my case Xfinity was 302 redirecting to safebrowse.io. To fix go to the app => Home => Advanced Security => turn this off.

Reply

Thanks for looking into this and sharing your results. Using curl and regular http revealed the following:

curl -v http://json-agrberg.koyeb.app
* Host json-agrberg.koyeb.app:80 was resolved.
* IPv6: 2606:4700:10::ac42:acae, 2606:4700:10::6814:1f1b
* IPv4: 104.20.31.27, 172.66.172.174
*   Trying [2606:4700:10::ac42:acae]:80...
* Connected to json-agrberg.koyeb.app (2606:4700:10::ac42:acae) port 80
> GET / HTTP/1.1
> Host: json-agrberg.koyeb.app
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 302 Found
< Location: https://www.safebrowse.io/warn.html?url=http://json-agrberg.koyeb.app/&token=6608dde5
< Connection: close
< Content-Length: 0
<
* Closing connection

I found the 302 to safebrowse.io odd. A search revealed Xfinity is the culprit. I’ll update the original post that you must disabled Xfinity’s “Advanced Security.” I didn’t consider my ISP would hijack requests