Making SSL tests all pass for Phoenix + Let's Encrypt

Thanks! @ericmj and I have pushed ranch 1.3 to hex now.

6 Likes

Thank you everybody, after spending some time testing and trying to fulfill every single one of the items in the ssl tests, I have

  • Used the version of Ranch, 1.3.1, which was just pushed to Hex.
  • That did the trick; the params (in the :atom format) are now recognized
  • (did not put honor_ecc_order param, as it might be unnecessary)
  • Added an additional client_renegotiation: false, param as without this the test score for HtBridge will be capped lower

Now I get A+ on HtBridge SSL test, and

capped to A- on SSLlabs test - because “The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-.”

  • Without knowing what the “reference browsers” need (or in fact, what they even are) I don’t think I can improve on this Forward Secrecy thing (might not be necessary to also)
  • HtBridge indicates “SERVER DOES NOT SUPPORT OCSP STAPLING” which is required for “Non-compliant with HIPAA guidance” but I think this is about the webserver implementation.

All in all, an immensely gratifying result from the built-in default webserver of Phoenix alone, guess that might be good enough for me and anyone else who might like to repeat this result can use the config params mentioned…

(If one wants to fulfil everything, then perhaps phoenix needs to be run behind nginx with its well-known params configured but this option didn’t appeal to me (for now.))

I am so impressed and grateful with the help given by this community… one of the best tech communities I’ve ever joined so far. :grinning:

6 Likes

Thanks for sharing your experience, would love to read your article about this setup a-z :slight_smile:

5 Likes

Yes this would be awesome to have!

3 Likes

Good, we’re getting closer, but we’re not there yet.

The message regarding forward secrecy from SSLLabs suggests you have cipher suites enabled that do not use a DH exchange. The :ciphers parameter in your configuration file does list only DH-enabled suites, but unfortunately Erlang’s :ssl module is silently ignoring the list and using its built-in defaults instead. I think you’ll find that the cipher list in the SSLLabs report does not match the list in your config file.

Erlang’s :ssl module expects cipher suite names to be passed in as charlists (not as Elixir strings, which are Erlang binaries; not sure why it’s silently ignoring binaries, though). And moreover, the names need to use OpenSSL naming conventions. So instead of…

ciphers: ~w(
  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  # ...
)

…you’d have to use…

ciphers: ~w(
  ECDHE-ECDSA-AES128-GCM-SHA256
  ECDHE-ECDSA-AES256-GCM-SHA384
  # ...
)c

(Note the c modifier at the end of the ~w sigil)

Shameless plug: you can use https://hex.pm/packages/cipher_suites to select cipher suites using the OpenSSL filtering syntax often used in Apache/Nginx/… instead.

Regarding OCSP stapling: this is not currently supported by Erlang’s SSL/TLS implementation.

7 Likes

Hi everyone here, many thanks for your help, and for your interest! :slight_smile:

So, now I am Proud Asian Dad, as it is possible to get A+ for BOTH ssllabs and htbridge’s ssl tests:

This:

and this:

Ok, let me see if I can provide a step by step here as an article might take too long.

1/ Basically, googling for “let’s encrypt” may eventually bring you to “certbot” which following the instructions here, you ssh into your server and follow step by step.

This obtains free SSL certs and auto-renews them using cron jobs.
A word here, the scripts by default run as root, so you may want to explore further at this stage “automated but not as root”

But if you want to just get everything running quickly to try out, you can just follow the original instructions.

2/
Next is you put the settings in your config file (e.g. dev.exs or another)
I just put the settings here that get you the A+ result above…
Also left in the commented-out options, to show that I found that they were not necessary (but others could tell more about these if they know more about them)

config :hello_phoenix, HelloPhoenix.Endpoint,
  http: [port: 80],

  #force_ssl: [rewrite_on: [:x_forwarded_proto]],
  url: [host: "asdf.qwer.com"],
  force_ssl: [],
  https: [port: 443,
          otp_app: :hello_phoenix,
          keyfile: "/PATH/TO/asdf.qwer.com/privkey.pem",
          certfile: "/PATH/TO/asdf.qwer.com/cert.pem",
          cacertfile: "/PATH/TO/asdf.qwer.com/chain.pem",
          versions: [:"tlsv1.2", :"tlsv1.1", :"tlsv1"],
          ciphers: ~w(
            ECDHE-ECDSA-AES256-GCM-SHA384
            ECDHE-ECDSA-AES256-SHA384
            ECDHE-ECDSA-AES128-GCM-SHA256
            ECDHE-ECDSA-AES128-SHA256
            ECDHE-ECDSA-AES256-SHA
            ECDHE-ECDSA-AES128-SHA

            ECDHE-RSA-AES256-GCM-SHA384
            ECDHE-RSA-AES256-SHA384
            ECDHE-RSA-AES128-GCM-SHA256
            ECDHE-RSA-AES128-SHA256
            ECDHE-RSA-AES256-SHA
            ECDHE-RSA-AES128-SHA

            ECDH-ECDSA-AES256-GCM-SHA384
            ECDH-ECDSA-AES256-SHA384
            ECDH-ECDSA-AES128-GCM-SHA256
            ECDH-ECDSA-AES128-SHA256

            DHE-RSA-AES256-GCM-SHA384
            DHE-RSA-AES256-SHA256
            DHE-DSS-AES256-GCM-SHA384
            DHE-DSS-AES256-SHA256
            DHE-RSA-AES256-SHA
            DHE-DSS-AES256-SHA

            DHE-DSS-AES128-GCM-SHA256
            DHE-RSA-AES128-GCM-SHA256
            DHE-RSA-AES128-SHA256
            DHE-DSS-AES128-SHA256
            DHE-RSA-AES128-SHA
            DHE-DSS-AES128-SHA

            AES128-GCM-SHA256
            AES128-SHA
            DES-CBC3-SHA
          )c,
          dhfile: "/PATH/TO/projects/hello_phoenix/dh-params.pem",
          secure_renegotiate: true,
          reuse_sessions: true,
          honor_cipher_order: true,
          # http://erlang.org/doc/man/ssl.html#type-ssloption
###          honor_ecc_order: true,
          client_renegotiation: false,
          eccs: [
            :sect571r1, :sect571k1, :secp521r1, :brainpoolP512r1, :sect409k1,
            :sect409r1, :brainpoolP384r1, :secp384r1, :sect283k1, :sect283r1,
            :brainpoolP256r1, :secp256k1, :secp256r1, :sect239k1, :sect233k1,
            :sect233r1, :secp224k1, :secp224r1
          ],
  ],

3/ As @voltone pointed out, if you used a wrong format for the ciphers, they will be silently ignored and the default suites used, that gets you A- or something else. If you use the one as shown here, they will be correct.

4/ So now running the tests on your server would give the same result.
‘OSCP Stapling’ item is not supported by the webserver, but that’s not quite important and there’s nothing you can do about it as well.

5/ I did not happen to try out (plug!) @voltone’s https://hex.pm/packages/cipher_suites since I only got to know of it so late, but I expect that you will get the same good result in one step rather than doing it by hand as I did (looking up and copying the openssl aliases) :smiley: If you do try it, do let us know how it works!

11 Likes

Nice. great and compact tutorial for others. :smiley: Thanks again for sharing your experience! :slight_smile:

3 Likes

Most welcome, glad to help, also, before I forget, these params are necessary, and give the behaviour of:

1/
If you access asdf.qwer.com on your browser, the webserver will automatically redirect from port 80 to port 443.

If you didn’t specify the http: [port: 80] param, then your server will not be listening on port 80 to give you this behaviour, which is likely what you would want to have

2/
The force_ssl: [], param is what specifies this behaviour also, although the “blank param” is confusing, but putting it like this in fact specifies a truthy value that will cause the auto-redirect mentioned

3/
Also, if you have a webserver served out http at port 5440, and your https is served out at port 5443, you need to put url: [host: "asdf.qwer.com:5443"], so that the auto-redirect happens correctly.

In my case, I had a webserver with a self-signed cert in development, so I did it like so: url: [host: "192.168.56.101:5443"],

So it takes a combination of these 3 params to get the behaviour. Excerpt pasted below.

4 Likes

I believe the force_ssl: [] works because it has a default of hsts: true. So leaving it blank means its actually
force_ssl: [hsts: true]

3 Likes

This greatly helped me to configure my standalone Erlang server running a Phoenix app to go from grade B to grade A+.

The current recommend ciphers suite from SSL labs are as per I have in my configuration:

# LINKS:
#   - Phoenix:
#     + https://elixirforum.com/t/making-ssl-tests-all-pass-for-phoenix-lets-encrypt/3507/11
#   - Erlang:
#     + http://ezgr.net/increasing-security-erlang-ssl-cowboy
#   - Cipher Suites:
#     + Best Ciphers - https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites
#     + Mapping - https://testssl.sh/openssl-rfc.mapping.html
#     + OWASP - https://www.owasp.org/index.php/TLS_Cipher_String_Cheat_Sheet
config :rumbl, Rumbl.Endpoint,
  http: [port: 4000],
  url: [
    host: System.get_env("APP_URL") || "${APP_URL}",
    port: System.get_env("APP_URL_HTTPS_PORT") || "${APP_URL_HTTPS_PORT}"
  ],
  force_ssl: [
    hsts: true
  ],
  https: [
    port: System.get_env("APP_HTTPS_PORT") || "${APP_HTTPS_PORT}",
    keyfile: System.get_env("APP_SSL_KEY_PATH") || "${APP_SSL_KEY_PATH}",
    certfile: System.get_env("APP_SSL_CERT_PATH") || "${APP_SSL_CERT_PATH}",
    cacertfile: System.get_env("APP_SSL_INTERMEDIATE_CERT_PATH") || "${APP_SSL_INTERMEDIATE_CERT_PATH}",
    dhfile: System.get_env("APP_SSL_DHPARAMS_PATH") || "${APP_SSL_DHPARAMS_PATH}",
    versions: [:'tlsv1.2'],
    ciphers: ~w(
      ECDHE-ECDSA-AES128-GCM-SHA256
      ECDHE-ECDSA-AES256-GCM-SHA384
      ECDHE-ECDSA-AES128-SHA
      ECDHE-ECDSA-AES256-SHA
      ECDHE-ECDSA-AES128-SHA256
      ECDHE-ECDSA-AES256-SHA384
      ECDHE-RSA-AES128-GCM-SHA256
      ECDHE-RSA-AES256-GCM-SHA384
      ECDHE-RSA-AES128-SHA
      ECDHE-RSA-AES256-SHA
      ECDHE-RSA-AES128-SHA256
      ECDHE-RSA-AES256-SHA384
      DHE-RSA-AES128-GCM-SHA256
      DHE-RSA-AES256-GCM-SHA384
      DHE-RSA-AES128-SHA
      DHE-RSA-AES256-SHA
      DHE-RSA-AES128-SHA256
      DHE-RSA-AES256-SHA256
    )c,
    secure_renegotiate: true,
    client_renegotiation: false,
    reuse_sessions: true,
    honor_cipher_order: true,
    max_connections: :infinity
  ],
  cache_static_manifest: "priv/static/manifest.json",
  server: true
1 Like

In case anyone comes across this post like I did, and wonders what the minimal config would be as of July 2020 to get an A+ on both SSL Labs and ImmuniwebSSL (htbridge) using a Let’s Encrypt certificate, here it is:

 https: [
    port: System.get_env("HTTPS_PORT"),
    keyfile: System.get_env("TLS_KEY_FILE"),
    certfile: System.get_env("TLS_CERT_FILE"),
    dhfile: "/etc/ssl/dhparam.pem",
    cipher_suite: :strong,
    client_renegotiation: false,
    transport_options: [socket_opts: [:inet6]]
  ]

The TLS_KEY_FILE being the privkey.pem and the TLS_CERT_FILE the fullchain.pem that are generated by certbot.

1 Like

Hi, I have tried most of these but i still get this error here:

setting up SSL correctly on an erlang/ elixir server - Stack Overflow.

Any help please.

1 Like

openssl s_client -connect paperlesssolutionsltd.com.ng:8443

gives:

λ openssl s_client -connect paperlesssolutionsltd.com.ng:8443
CONNECTED(000001B8)
depth=0 CN = www.paperlesssolutionsltd.com.ng
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = www.paperlesssolutionsltd.com.ng
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:CN = www.paperlesssolutionsltd.com.ng
   i:C = US, O = Let's Encrypt, CN = R3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGiTCCBXGgAwIBAgISBJEvL3uT8YZMvG0HGiFugEe9MA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTAyMDUxMTAyNTNaFw0yMTA1MDYxMTAyNTNaMCsxKTAnBgNVBAMT
IHd3dy5wYXBlcmxlc3Nzb2x1dGlvbnNsdGQuY29tLm5nMIICIjANBgkqhkiG9w0B
AQEFAAOCAg8AMIICCgKCAgEA/pJFz2InXO8UiTggt3ThP3tiIiipVWfGzteHLI7S
6VhJRjv+/W+Mcu5EXXdVum/1ZTe6E1Ko/i0qrqvwvBNhuCCI0EnK5H299jAICt0/
JnSTDp1JDz2k7Nm0MIiIEZfvaIRXuoopR4iM91svIku6D3rzZ+OwoTUvZXvEscky
pBJc+fVUJvfnGhDwLqLXvXyzXqapKphrGxAAHD2GzxOEGo33N3N97m18qbyeG+hA
UOcIRVfLP2jPrWDolKchtM9AyUj4lAiMsPU7Jc+Rt6AnMyTr1hsXduUCNNn3i/h/
s7Kg3xIo++izDhC9Qj5Pedgy2pbZ6z4ZMKQ9UsPGHJ6X3BmT7lgX796nGeaySC+L
HqwBtoAlFMwE96i4yNEhFlQuM5roNhlVc4Vv5yyvtVNtxoYMGpsrJ0upAWHmJ+0J
UJVlCcemng+7eSfNBrdZ1XvSvHxSqPEOmmn7gqdBzad3PKj9inkibtmSqt9gNOGR
RzI0DZK8CE52LUrqBNrUsifmE8uw/FQ11+7eahL65b0nNj0wreExONb0aQEYOR1/
/4YXK742K3l4hZn5r/sIuzgYFFIZwIKckYi821EHE3ugwPG3asBXBaZ9vSZ5CFt+
vAzedpTNV3nN/55KlqHhll98FF6JQAFNsGRY5kcWC2SVv/KRIczrfVm2R/USVXOX
iWcCAwEAAaOCAp4wggKaMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEF
BQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUnReY/FdZAB8x
NTbPm+A1kBqwgAYwHwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsUwsYwVQYI
KwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vcjMuby5sZW5jci5vcmcw
IgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9yZy8wbAYDVR0RBGUwY4Ih
bWFpbC5wYXBlcmxlc3Nzb2x1dGlvbnNsdGQuY29tLm5nghxwYXBlcmxlc3Nzb2x1
dGlvbnNsdGQuY29tLm5ngiB3d3cucGFwZXJsZXNzc29sdXRpb25zbHRkLmNvbS5u
ZzBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUF
BwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQYGCisGAQQB1nkCBAIE
gfcEgfQA8gB3AESUZS6w7s6vxEAH2Kj+KMDa5oK+2MsxtT/TM5a1toGoAAABd3IS
1lkAAAQDAEgwRgIhAODIbmogAX5fAQ8pKfAlEbZMFJYqksp3iInqCepNymN3AiEA
zdJOaSOHe2A78x9thbdf8WCndV/rPVLw0tME6hzpW6QAdwD2XJQv0XcwIhRUGAgw
lFaO400TGTO/3wwvIAvMTvFk4wAAAXdyEtZZAAAEAwBIMEYCIQD8FomGRVUtXy5e
XByxhM383UUKt+35L217GUAZ7FUgjwIhANrw1gax+fOWp6qRLpBFDz7S3D9SL5RA
KHWQYOJmM8ciMA0GCSqGSIb3DQEBCwUAA4IBAQCU1EzS7Lt1hAZ4+WtPisM+B8R/
RKJ72PTE+E8dHB+SlNeFoJGpj5Z4FO9bp69fdOcG6D2NxJBDVc1VCR7Gx20Sxngs
wm9CexnRlsRaWuXLTJoxn/QoQ+kEWRIIYVXaa7MmlkljpTGLHkBHpwOT7/rtmgpB
geUmgjia+hlah2jltYP6QwhXriOXuhUU/DltAm8S2yS8ITtIIe/0yCXy3CilY7Um
0qtQW5lDecCqZtYlBGwNtoJbAWJrAnlMavdlM6Z1ziRh33BiPQXKNFfBk2P9kBmA
Yud7vIIOK5SB5KhZ45WWm2Tmu2ZsHPu+iaDR+rQB68BOi1aQY0P6+JbY6V1j
-----END CERTIFICATE-----
subject=CN = www.paperlesssolutionsltd.com.ng

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2489 bytes and written 410 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 21 (unable to verify the first certificate)
---

HTTP/1.1 400 Bad Request
connection: close
content-type: text/plain
content-length: 19

Invalid line:


closed

c:\Projects
λ

The intermediate certs are not being sent. Please is there aa config needed for erlang ssl to send the intermediate certs?

I have tried both Elli and Ace servers

The cert.pem file from Let’s Encrypt contains only the end certificate. You should also have a file called fullchain.pem containing the end certificate and any associated intermediates. If you point the :certfile option to the fullchain.pem file, your server should send those intermediates in the handshake.

(There are some more subtleties, but in most cases this should be enough to get going)

I have obtained the full-chain.pem by combining both my cert.pem and the intermediate cert from lets-encrypt.

The result is still the same.

Can you share the contents of your cert.pem file?

Unlike many other servers, Erlang/OTP’s ssl does not blindly copy the contents of the file into the TLS handshake. Instead, it inspects the end certificate and then looks for its issuer certificate (recursively) using the available CA certificates. If you specify the :cacertfile/:cacerts option, then it will look for the intermediates there, rather than in the file :certfile points to. Of you don’t, then it falls back to looking in :certfile for the intermediates.

It sounds like in your case this process does not result in a valid issuer for your end certificate, so none is sent in the handshake. The question is why exactly…

Could it be the line break between the two certificates is not a newline, but maybe CR or a space? Try opening the file and adding one or more new lines just before “-----BEGIN CERTIFICATE-----”.

I have adjusted like you suggested.

-----BEGIN CERTIFICATE-----
MIIGiTCCBXGgAwIBAgISBJEvL3uT8YZMvG0HGiFugEe9MA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTAyMDUxMTAyNTNaFw0yMTA1MDYxMTAyNTNaMCsxKTAnBgNVBAMT
IHd3dy5wYXBlcmxlc3Nzb2x1dGlvbnNsdGQuY29tLm5nMIICIjANBgkqhkiG9w0B
AQEFAAOCAg8AMIICCgKCAgEA/pJFz2InXO8UiTggt3ThP3tiIiipVWfGzteHLI7S
6VhJRjv+/W+Mcu5EXXdVum/1ZTe6E1Ko/i0qrqvwvBNhuCCI0EnK5H299jAICt0/
JnSTDp1JDz2k7Nm0MIiIEZfvaIRXuoopR4iM91svIku6D3rzZ+OwoTUvZXvEscky
pBJc+fVUJvfnGhDwLqLXvXyzXqapKphrGxAAHD2GzxOEGo33N3N97m18qbyeG+hA
UOcIRVfLP2jPrWDolKchtM9AyUj4lAiMsPU7Jc+Rt6AnMyTr1hsXduUCNNn3i/h/
s7Kg3xIo++izDhC9Qj5Pedgy2pbZ6z4ZMKQ9UsPGHJ6X3BmT7lgX796nGeaySC+L
HqwBtoAlFMwE96i4yNEhFlQuM5roNhlVc4Vv5yyvtVNtxoYMGpsrJ0upAWHmJ+0J
UJVlCcemng+7eSfNBrdZ1XvSvHxSqPEOmmn7gqdBzad3PKj9inkibtmSqt9gNOGR
RzI0DZK8CE52LUrqBNrUsifmE8uw/FQ11+7eahL65b0nNj0wreExONb0aQEYOR1/
/4YXK742K3l4hZn5r/sIuzgYFFIZwIKckYi821EHE3ugwPG3asBXBaZ9vSZ5CFt+
vAzedpTNV3nN/55KlqHhll98FF6JQAFNsGRY5kcWC2SVv/KRIczrfVm2R/USVXOX
iWcCAwEAAaOCAp4wggKaMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEF
BQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUnReY/FdZAB8x
NTbPm+A1kBqwgAYwHwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsUwsYwVQYI
KwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vcjMuby5sZW5jci5vcmcw
IgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9yZy8wbAYDVR0RBGUwY4Ih
bWFpbC5wYXBlcmxlc3Nzb2x1dGlvbnNsdGQuY29tLm5nghxwYXBlcmxlc3Nzb2x1
dGlvbnNsdGQuY29tLm5ngiB3d3cucGFwZXJsZXNzc29sdXRpb25zbHRkLmNvbS5u
ZzBMBgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUF
BwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQYGCisGAQQB1nkCBAIE
gfcEgfQA8gB3AESUZS6w7s6vxEAH2Kj+KMDa5oK+2MsxtT/TM5a1toGoAAABd3IS
1lkAAAQDAEgwRgIhAODIbmogAX5fAQ8pKfAlEbZMFJYqksp3iInqCepNymN3AiEA
zdJOaSOHe2A78x9thbdf8WCndV/rPVLw0tME6hzpW6QAdwD2XJQv0XcwIhRUGAgw
lFaO400TGTO/3wwvIAvMTvFk4wAAAXdyEtZZAAAEAwBIMEYCIQD8FomGRVUtXy5e
XByxhM383UUKt+35L217GUAZ7FUgjwIhANrw1gax+fOWp6qRLpBFDz7S3D9SL5RA
KHWQYOJmM8ciMA0GCSqGSIb3DQEBCwUAA4IBAQCU1EzS7Lt1hAZ4+WtPisM+B8R/
RKJ72PTE+E8dHB+SlNeFoJGpj5Z4FO9bp69fdOcG6D2NxJBDVc1VCR7Gx20Sxngs
wm9CexnRlsRaWuXLTJoxn/QoQ+kEWRIIYVXaa7MmlkljpTGLHkBHpwOT7/rtmgpB
geUmgjia+hlah2jltYP6QwhXriOXuhUU/DltAm8S2yS8ITtIIe/0yCXy3CilY7Um
0qtQW5lDecCqZtYlBGwNtoJbAWJrAnlMavdlM6Z1ziRh33BiPQXKNFfBk2P9kBmA
Yud7vIIOK5SB5KhZ45WWm2Tmu2ZsHPu+iaDR+rQB68BOi1aQY0P6+JbY6V1j
-----END CERTIFICATE-----


-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIk
XPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----

same result.

Hmm, just to rule out file encoding issues altogether, when you run :public_key.pem_decode(File.read!("cert.pem")) in iEX, do you get a list with one or two certificates?