Closed mikefogg closed 5 years ago
Hi @mikefogg,
I believe when you're calling Acme::Client:CertificateRequest.new()
without proving an explicit private key a new one is generated for you because the default private_key
argument is generate_private_key
: https://github.com/unixcharles/acme-client/blob/38f4e17bc9e4ec21c3a417a085d843d1fb7f8b4d/lib/acme/client/certificate_request.rb#L28
As you discovered since the account key doesn't match the key in the CSR you aren't able to verify the certificate signature with it and neither is Heroku.
It would be tempting to fix that by providing your key_object
to the CSR initializer but that won't work because you're already using key_object
as the ACME account key in Acme:Client.New()
and Let's Encrypt specifically forbids reusing your ACME account public key as a certificate subject public key.
I think the correct solution is for you to either:
Acme::Client::CertificateRequest.new()
and upload that key to Heroku(FWIW I'm not a Ruby dev or an acme-client dev I just know my way around ACME so definitely take my help with a grain of salt!)
Yep, @cpu is right.
Hey guys,
Banging my head against the wall here trying to figure this out.
Can anyone shed some light into why this isn't returning true? I'm passing the private key object directly through to my Acme Client and then attempting to upload the private/public pair to Heroku... but somehow they don't match (even though I literally just made it).
(I've ignored the uploading to heroku part since the "verify" method fails regardless)