Apple SSL certificate updated. How do I get Pigeon to use the new pem on the active server?

[Sinc63]

Environment

• Elixir & Erlang/OTP versions (elixir --version):
  Erlang/OTP 26 [erts-14.2.5] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [jit:ns]

Elixir 1.16.3 (compiled with Erlang/OTP 26)

• Operating system: OS9
• Pigeon version: 2.0.0-rc2

Current behavior

Our Apple SSL certificate expired yesterday in our environment sending pushes through Pigeon. I have the certificate defined in the config file using file.read!. Now that I've got a new pem file, is there a way to install that on the operating server running the app, and update the environment variables to read the new pem and use it?
I tried creating a new value for the Application.put_env(:myapp, Myapp.APNS.Prod) with the cert containing the new content, then tried restarting the process Myapp.APNS.Prod, but I'm still being flooded with errors like
[info] function=decode/3 line=136 module=ssl_alert TLS :client: In state :connection received SERVER ALERT: Fatal - Certificate Expired

Expected behavior

I'm hoping not to have to build a new load every year when the APPLE certs expire, So I need a way to install the pem in the running system and get the system to make use of it.
How do I update the config on a running system and get it to take effect?

[Sinc63]

The Certificate Expired Errors are happening about 5-6 times per second. What is causing that, and is there anything I can do to throttle that back. I don't want to get blacklisted by Apple.

[nkezhaya]

@Sinc63 Did you ever figure this out? I'm also running into this issue.

[Sinc63]

@nkezhaya I did end up having to create a new build to solve this, but it should prevent having to do it again next year. Move the configuration of your adapters into config/runtime.exs instead of config/config.exs. Since I was reading the pem files in the config I had to change the File.read! to insert the application directory in front, but it should work fine when you update the pems later and just reload.
That is:
cert: File.read!(Path.join(Application.app_dir(:myapp), "priv/aps.pem"))

[hpopp]

This is on my roadmap to address this year and make the developer quality of life a little better. The crashing and reconnecting has been a long standing issue with how Kadabra was originally designed, so I will likely switch to mint/finch to handle connections and implement some sort of graceful unauthorized error on push dispatch. That said, you still have to be disciplined to renew certs on time.

If you don't want to have to renew certs every year, I recommend switching to the JWT setup. Example config is in the docs.

[lukasz-szulborski]

@Sinc63 Did you ever figure this out? I'm also running into this issue.

I'm also running into this issue. My setup is a bit problematic in that scenario thought, because I'm using a dispatcher with an open connection and I use certificates saved in a database. It is the client, not me who uploads and keeps certificates up to date. So if the cert is expired, I have no control over updating it and I'm flooded with these TLS errors mentioned earlier which also causes memory leak I think.

[Sinc63]

As I said above, I changed my configuration for the certificates to be in the runtime config. With what you say about things, after you change to a runtime model the client that is uploading the certificates to your database will also have to upload them to the system and reboot. Sinc

…

On Wed, Apr 30, 2025 at 2:47 PM Łukasz Szulborski ***@***.***> wrote: *lukasz-szulborski* left a comment (codedge-llc/pigeon#292) <#292 (comment)> @Sinc63 <https://github.com/Sinc63> Did you ever figure this out? I'm also running into this issue. I'm also running into this issue. My setup is a bit problematic in that scenario thought, because I'm using a dispatcher with an open connection and I use certificates saved in a database. It is the client, not me who uploads and keeps certificates up to date. So if the cert is expired, I have no control over updating it and I'm flooded with these TLS errors mentioned earlier which also causes memory leak I think. — Reply to this email directly, view it on GitHub <#292 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKNZTDL3L6QWJ77OHG7AZYT24ELELAVCNFSM6AAAAABXANQQW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBSHE3DQOBQGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>