SSL certificate on port distinct from 443 voids for <myapp> domain


I need a TLS service with custom port having ssl certificate enabled. I wouldn’t like to stick with own domain for now on as is enough for me. I found out port number matters as if I tie 443 to the app it’s ok, but any other number breaks things down. Is any possibility to enable it somehow or may be I missed something? As I found nothing in community knowledge base.

The services section is as follows. If I change port = 443 to port = 853 it stops working.

  protocol = "tcp"
  internal_port = 53

    port = 443
    handlers = ["tls"]
    type = "connections"
    hard_limit = 150
    soft_limit = 100

    interval = "15s"
    timeout = "2s"
    grace_period = "30s"

Would any kind soul shed some light on this? Thanks.

I can confirm that I tried port 3000 a few weeks ago and found the same issue. Typing https in the browser did not resolve it.

For me this was because I was trying to having another process group expose the backend, but could not use 443, as the primary process (website) was using it.

I did not find a work around. I ended up spinning up a separate app for what was previous an additional process group.

Before I thought may be my own domain is necessary with explicit certificate issued to the domain with flyctl certs add <hostname>. I got one, but actually it doesn’t work either.

Could there be the reason that I have shared ip? As I have warning in admin UI

Checking SSL handshake with openssl gives me this.

openssl s_client -connect
40772DD6427F0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:ssl/record/rec_layer_s3.c:303:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 327 bytes
Verification: OK
New, (NONE), Cipher is (NONE)
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

But changing port to 443 fixes the issue up.

openssl s_client -connect
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 = R3
verify return:1
depth=0 CN =
verify return:1
Certificate chain
 0 s:CN =
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep 27 10:37:26 2023 GMT; NotAfter: Dec 26 10:37:25 2023 GMT
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT

Yep, acutally it’s due to --shared ip4.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.