Remote server silently falls back to HTTP when `tls.eca.dev` serves SEC1 private key

[MrnoRac]

To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.

tls.eca.dev serves local-eca-dev-privkey.pem in SEC1/traditional EC format (BEGIN EC PRIVATE KEY). parse-private-key in tls.clj only handles PKCS#8 (BEGIN PRIVATE KEY) — it wraps the raw bytes in PKCS8EncodedKeySpec and tries RSA then EC, both of which return nil for SEC1 input. ssl-context gets nil back and silently starts the server HTTP-only with no clear error to the user beyond the generic warn log.
A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:
curl -s https://tls.eca.dev/local-eca-dev-privkey.pem | head -1
-----BEGIN EC PRIVATE KEY----- ← SEC1, not PKCS#8

(require '[eca.remote.tls :as tls])

;; Fetch exactly what tls.eca.dev serves
(def sec1-key (slurp "https://tls.eca.dev/local-eca-dev-privkey.pem"))

(println (first (clojure.string/split-lines sec1-key)))
;; => -----BEGIN EC PRIVATE KEY-----   (SEC1, not PKCS#8)

(#'tls/parse-private-key sec1-key)
;; => nil   (expected: a PrivateKey instance)

Expected behavior
(def pkcs8-key (slurp (clojure.java.io/resource "eca/remote/fixtures/valid-privkey.pem")))
(#'tls/parse-private-key pkcs8-key)
;; => #object[sun.security.ec.ECPrivateKeyImpl ...]

it should give me a valid key object back

Recommended fix
re-issue tls.eca.dev/local-eca-dev-privkey.pem in PKCS#8 format:

openssl pkcs8 -topk8 -nocrypt -in ec-privkey-sec1.pem -out privkey.pem

I'm not sure how these are generated or when, or if there's a reason it has to be EC.
if it has to be EC let's update the tests and then we just have to handle SEC1 correctly in the parse-private-key fn.

[MrnoRac]

For anyone running into this here is a Workaround

Convert the cached key to PKCS#8 in place, then restart ECA:

openssl pkcs8 -topk8 -nocrypt \
  -in ~/.cache/eca/tls/local-eca-dev-privkey.pem \
  -out /tmp/k.pem && mv /tmp/k.pem ~/.cache/eca/tls/local-eca-dev-privkey.pem