I recently started testing Posh-ACME against ssl.com's new ACME endpoints. The object URIs make it seem like they're running some version of EJBCA under the hood. So this may not be something they can directly fix if it is indeed a bug.
In any case, the problem I'm currently running into is that their ACME server is throwing an error when I do a standard POST-as-GET request to my account's URL (to verify it's still valid among other things). Here's an example of the debug output showing the request and response details. I should mention that this code works just fine against LE, BuyPass, and ZeroSSL.
Can anyone else confirm the problem with another client? You'll need to register a website account first in order to get the required EAB credentials. It happens with both their RSA and ECC directory endpoints: https://acme.ssl.com/sslcom-dv-rsa https://acme.ssl.com/sslcom-dv-ecc
Does their version of EJBCA just not support POST-as-GET requests? You get the same error if you try an unauthenticated GET against the account URI.
It also bugs me that the error body JSON doesn't have any of the RFC 7807 "Problem Details" members (like type in particular).
More testing results. I get the same error even with a valid non-empty payload trying to update the contact field on my account:
I can confirm from the headers implementation is running on AWS, hosted on WildFly (JBoss) and that the RSA account path seems to be working (https://acme.ssl.com/ejbca/acme/sslcom-dv-rsa/acct/<acc id>)
Another thing I noticed is that they let your re-use EAB credentials, whereas some others don't.
The AWS link is a great find and the response headers do make it seem like it's CloudFront throwing the error before the request even makes it to EJBCA.
The brief searching I've done on the error in relation to AWS makes it sound like it's a common mistake when you're either using the wrong HTTP verb or the wrong endpoint. But neither should be the case here because POST is definitely the right verb and the endpoint was provided by the server.
If I ignore the errors doing account related stuff, I can actually move forward and create a new order using the account and even successfully authorize the DNS challenges. But when I try to finalize the order, they throw an error because apparently they're expecting an email address to be included in the CSR.
{
"detail": "Email address cannot be empty or null.. If you need assistance, please contact support@ssl.com",
"type": "urn:ietf:params:acme:error:badCSR"
}
What sort of crazy pants requirement is that on a DV cert?
Interesting, again maybe you are still using an EC key and that forces it down a non-working path. Certify doesn't put an email address in the CSR either, but the RSA path passes.
Apparently this is just a bad error message. The ACME account I was using was created with an empty contact field. I created a new one (since I still can't update an existing one) with an email address and now the finalization works.
Seems like if they want to enforce an email address on the ACME account, they should do that at creation time! Especially since their account endpoints are so broken they can't be updated.
Hey @webprofusion, do you recall the error message you got when attempting to get a cert from the EC path? I can get as far as the finalization step where I'm sending the CSR (with a P-256 key) and I get the following error:
{
"type": "urn:ietf:params:acme:error:badCSR"
"detail": "Requested key usage will not be granted.. If you need assistance, please contact\r\nsupport@ssl.com",
}
Curious if it's the same error you got. Also wondering if there's actually something they don't like about the CSR or if this is another "bad" error message and it's the server's way of saying they don't actually offer ECC certs yet.
Just a random thought, but that could be related to the OIDs related to (extended) key usage that are included in the CSR. I mean for signing and whatnot.
Appreciate the thought, but it's unlikely. It's the same code generating the CSR regardless of the ACME server. It only includes Digital Signature and Key Encipherment in the standard key usage and the normal Client + Server authentication OIDs in the extended key usage. The same values work for their RSA endpoint.
Yes, I had two issues, one was that the certes library I use was constructing a csr that also asked for NonRepudiation for some reason. After contacting the ssldotcom support they told me what the issues was. I then got the RSA chain working, but couldn't find a key spec (ES256 etc) that would worked for the EC chain so gave up on that.
If RSA is also working for you and EC isn't you could try contacting support to see if they can tell you anything, or try it with certbot.
Key Encipherment is not valid for ECDSA certificates. This is for "when the subject public key is used for enciphering private or secret keys, i.e., for key transport." (RFC 5280).
For example, you usually set this in RSA certs to allow for the old static RSA key exchange in TLS. As you can't encipher with ECDSA, this key usage is not valid for that type.
I believe Let's Encrypt (and probably other CA's) strip off the attribute automatically for you, if it's not valid. Maybe they don't?
Just to follow up. The Key Encipherment was definitely the solution to the finalization problem. But I still don't have a solution to the Account endpoint issues. I'll likely be emailing support about this to see what they say.
