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

Hi,

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 ...fly.dev 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.

[[services]]
  protocol = "tcp"
  internal_port = 53

  [[services.ports]]
    port = 443
    handlers = ["tls"]
  [services.concurrency]
    type = "connections"
    hard_limit = 150
    soft_limit = 100

  [[services.tcp_checks]]
    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
Screenshot_20230928_002401

Checking SSL handshake with openssl gives me this.

openssl s_client -connect adsfree.cloudns.ph:853
CONNECTED(00000003)
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 adsfree.cloudns.ph:443
CONNECTED(00000003)
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 = adsfree.cloudns.ph
verify return:1
---
Certificate chain
 0 s:CN = adsfree.cloudns.ph
   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.