ACME: secondary subdomain certificate request problem

JulienB · December 10, 2020, 9:49am

Hi,

We are investigating an issue using ACME (acme4j libraries using our own Java server) with certificate generation for secondary subdomains.
No problem when generating a certificate for a domain like xxx.mydomain.com. The request failed when requesting a certificate for yyy.xxx.mydomain.com with a urn:ietf:params:acme:error:malformed error from the server.
Is there any limitation or added constrains on the CSR that need to be filled when building the CSR for a secondary subdomain?

We are building the CSR using only domain name:
CSRBuilder csrb = new CSRBuilder();
csrb.addDomain(domain);
csrb.sign(domainKeyPair);

The CSR produced is the following:

The server replies with this error:
{"type":"urn:ietf:params:acme:error:malformed","detail":"Error unmarshaling finalize order request","status":400}

webprofusion · December 10, 2020, 10:44am

Note that when you submit your CSR to Let's Encrypt, it should be the Base64 encoded version of the CSR in DER format, without padding. So convert the CSR to DER (bytes), then get the base64 encoded version (without padding).

JulienB · December 10, 2020, 11:04am

The content of the request sent to the server looks like this:
{"protected":"eyJ1cmwiOiJodHRwczovL2FjbWUtc3RhZ2luZy12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2ZpbmFsaXplLzE3MDIwNzQ4LzE5OTU5MDU4MSIsImtpZCI6Imh0dHBzOi8vYWNtZS1zdGFnaW5nLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvYWNjdC8xNzAyMDc0OCIsIm5vbmNlIjoiMDAwNC0teWtHcXRJVGJHekpvTGdyN3M1VFRjVGphOVdFbjNJRm5CS2dicTgtTkEiLCJhbGciOiJSUzI1NiJ9","payload":"eyJjc3IiOiJNSUlDeURDQ0FiQUNBUUF3UmpFb01DWUdBMVVFQXd3ZmFuVnNhV1Z1TG1kbGJubHRiM1JwYjI0dWMyaGhhMkZ3WldGcmN5NW1jakVhXG5NQmdHQTFVRUNnd1JSMlZ1ZVcxdmRHbHZiaUJFWlhacFkyVXdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCXG5BUUNoYWpfY3hHQm90WlphZ3RUSnZDcmEzeE5MV0tHLUx6aHJYQ3JTdWFYVlNEUE53emtUTFBZUU42RHNlSnR1TU9vT0h6aVp1YnR6XG50em41aTBpMU5wM3V5TlpSWjREX0ZSZWpyNE9RWnlXM1IwcEtmRnVfUU95TmZ1cVY0XzhJNDFETUZTU1BLSkE1LTlndEJaX2l5c2lqXG41Rzl6TXE0ODBsaTd3VmFxZnVUajhJLWMyYThxV1RPWGpWSEN5Z1J2dDNhU18xbE9tMXFNZ2doNE0xN2ZpbzQwdi1nWGR6Ri01dTZOXG5GOXlLQzI2VnBheWRXTHUzX191eWFBZkFHc3AxVXl3Y2FPTmFhSjZpaVNUTDJEQmtEdDd2ME14NmJHZXlCZHByMEQ3NWJxbVZnTFNYXG5yM1AxcHR2X09DZm1mRXB2RGdQWnJaSldLbnNueGhtSGJ6anhteUNKQWdNQkFBR2dQVEE3QmdrcWhraUc5dzBCQ1E0eExqQXNNQ29HXG5BMVVkRVFRak1DR0NIMnAxYkdsbGJpNW5aVzU1Ylc5MGFXOXVMbk5vWVd0aGNHVmhhM011Wm5Jd0RRWUpLb1pJaHZjTkFRRUxCUUFEXG5nZ0VCQURHb1laTERaNWx1cmpTaXF3OUJlVW0zWmxnS2JRS1JtV1JPREtuVVZOQ3hsUTMxUTJva3JZaW5mcHoyQTB0bTJ2b3F5Nl9rXG5ZYkNsVGYzcmVLdEdCZ3RKbjlIalZWOVdpWDVtOVdxTHZjMXJjT0hxT1Z2cmRxbkc4dXZLWGZlOGNWQzlTMXZhWE1na3FTZnZIMlNPXG53RVlRQUE5YUF1YUkza3lBQUcwNFZnb0k3SGtuc0syeXRIOE1aRGRpLThWZmlfaXdFWVlPVm40NDFtWEZZdWctbUFmWFFtandTa2ZOXG40ai1uNG9KQlMyR0k2UU5kLUhGWDVHNm1DSklUS2xjSWZrV1hSbDhrYWlKbExsemZ6eFN4NHpjSHRKZTVkSURwZ1FHc0kzQkZ0NEpWXG5NZVN1azJSR3hhUEVFZVFsRUkxNzI4MXZfcDRLV3hXSlFzTHZBU2tUS3BzXG4ifQ","signature":"MTeOEM1Q5bDeDaz4iihwLqIjw8HNahiM3HQSc5iDVvkMs_ylyLT0TG5_pPgIYajdmtu37_4N7FDP3-PUmqu8eX7D3PeEXbzBPHVHR4UKyqtav9-z4-Vkm94r_183U2dPgI5JSVxJUscMdnoDvgVQGQyKX-FA3FXAMeEuoZnIM4bES4jzoqEhAYGP7APhg4AYyE2I2wgn_bphTHEic5_A2EhBPb2sAHTHo94DPG7L4Mxs-aRa8mWPidE-gu-TxDAdL_emr1tMmbzy-XdISv9kyVtB3Q1CykfYoXeG0qjiDYZnWN71cAkAeYe82aBVY5xrHd89rtm56gV6Qcug4OkJ-A"}

_az · December 10, 2020, 11:19am

The csr field of your payload contains encoded newlines (\n):

{"csr":"MIICyDCCAbACAQAwRjEoMCYGA1UEAwwfanVsaWVuLmdlbnltb3Rpb24uc2hha2FwZWFrcy5mcjEa\nMBgGA1UECgwRR2VueW1vdGlvbiBEZXZpY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB\nAQChaj_cxGBotZZagtTJvCra3xNLWKG-LzhrXCrSuaXVSDPNwzkTLPYQN6DseJtuMOoOHziZubtz\ntzn5i0i1Np3uyNZRZ4D_FRejr4OQZyW3R0pKfFu_QOyNfuqV4_8I41DMFSSPKJA5-9gtBZ_iysij\n5G9zMq480li7wVaqfuTj8I-c2a8qWTOXjVHCygRvt3aS_1lOm1qMggh4M17fio40v-gXdzF-5u6N\nF9yKC26VpaydWLu3__uyaAfAGsp1UywcaONaaJ6iiSTL2DBkDt7v0Mx6bGeyBdpr0D75bqmVgLSX\nr3P1ptv_OCfmfEpvDgPZrZJWKnsnxhmHbzjxmyCJAgMBAAGgPTA7BgkqhkiG9w0BCQ4xLjAsMCoG\nA1UdEQQjMCGCH2p1bGllbi5nZW55bW90aW9uLnNoYWthcGVha3MuZnIwDQYJKoZIhvcNAQELBQAD\nggEBADGoYZLDZ5lurjSiqw9BeUm3ZlgKbQKRmWRODKnUVNCxlQ31Q2okrYinfpz2A0tm2voqy6_k\nYbClTf3reKtGBgtJn9HjVV9WiX5m9WqLvc1rcOHqOVvrdqnG8uvKXfe8cVC9S1vaXMgkqSfvH2SO\nwEYQAA9aAuaI3kyAAG04VgoI7HknsK2ytH8MZDdi-8Vfi_iwEYYOVn441mXFYug-mAfXQmjwSkfN\n4j-n4oJBS2GI6QNd-HFX5G6mCJITKlcIfkWXRl8kaiJlLlzfzxSx4zcHtJe5dIDpgQGsI3BFt4JV\nMeSuk2RGxaPEEeQlEI17281v_p4KWxWJQsLvASkTKps\n"}

I think maybe you are using some weird way of generating this encoding. The right way would be to get the raw DER bytes (use a proper PEM decoder if necessary) and then maybe use acme4j's AcmeUtils.base64UrlEncode method to encode it.

JulienB · December 10, 2020, 11:27am

We are relying in acme4j to build the request and send it to the server. CSR is encoded in base64 here:

github.com

shred/acme4j/blob/master/acme4j-client/src/main/java/org/shredzone/acme4j/Order.java#L164


 * {@link Object#finalize()} method.
 *
 * @param csr
 *            CSR containing the parameters for the certificate being requested, in
 *            DER format
 */
public void execute(byte[] csr) throws AcmeException {
    LOG.debug("finalize");
    try (Connection conn = getSession().connect()) {
        JSONBuilder claims = new JSONBuilder();
        claims.putBase64("csr", csr);
        conn.sendSignedRequest(getFinalizeLocation(), claims, getLogin());
    }
    invalidate();
}
/**
 * Checks if this order is auto-renewing, according to the ACME STAR specifications.
 *
 * @since 2.3

I just put some debugging to get a dump of the request here:

github.com

shred/acme4j/blob/master/acme4j-client/src/main/java/org/shredzone/acme4j/connector/DefaultConnection.java#L456


}
conn = httpConnector.openConnection(url, session.networkSettings());
conn.setRequestMethod("POST");
conn.setRequestProperty(ACCEPT_HEADER, accept);
conn.setRequestProperty(ACCEPT_CHARSET_HEADER, DEFAULT_CHARSET);
conn.setRequestProperty(ACCEPT_LANGUAGE_HEADER, session.getLocale().toLanguageTag());
conn.setRequestProperty(CONTENT_TYPE_HEADER, "application/jose+json");
conn.setDoOutput(true);
JSONBuilder jose = JoseUtils.createJoseRequest(
        url,
        keypair,
        claims,
        session.getNonce(),
        accountLocation != null ? accountLocation.toString() : null
);
byte[] outputData = jose.toString().getBytes(StandardCharsets.UTF_8);
conn.setFixedLengthStreamingMode(outputData.length);

_az · December 10, 2020, 11:33am

Okay, that would suggest that the problem is with the data you're passing for the byte[] csr parameter. acme4j doesn't call any code which would be resulting in these newlines.

I think webprofusion is on the money and you're not providing the DER-encoded CSR.

JulienB · December 10, 2020, 6:57pm

Ok I found the issue:
We replaced the java.util.Base64 function by Android Base64 encoder for older Android versions using Java 7.

The default implementation does not remove LF and we just need to add the NO_WRAP flag.

That was really weird that the CSR was failing with only domains with secondary subdomains, but it is just a length problem. We didn't face problem with shorted domains because the first LF was just placed after the field containing the domain name on the first Base64 line ....

Thanks you for your help pointing to the \n,
Julien

rg305 · December 10, 2020, 11:29pm

So then it was actually always "broken" and had only "worked" by a lucky coincidence.
[some times luck lands in our favor ]

system · January 9, 2021, 11:43pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Error requesting new certificates Help	6	1116	May 27, 2018
There was a problem processing your request Help	9	1780	February 10, 2021
Urn:acme:error:malformed - Error unmarshaling certificate request Client dev	3	2202	August 17, 2016
Error while generating certificate Help	5	229	April 22, 2024
API returns error "urn:ietf:params:acme:error:malformed" Help	12	11968	June 17, 2021

ACME: secondary subdomain certificate request problem

Related topics