Saving account data fails when mod_md is not running as root anymore

[mkauf]

Usually the ACME account and the directory "accounts" in the MDStoreDir directory are created at startup, while the Apache Server is running as root.

After the startup, the Apache Server switches to the user/group that have been configured with the User and Group settings. Now mod_md cannot change the account data in the MDStoreDir directory anymore. Sometimes it tries to do it, see issue #409: md_acme_acct_validate() may call md_acme_acct_save(), this fails.

Not sure what mod_md should do, maybe save the updated account to a temporary directory and copy it to the real "accounts" directory on the next server startup?

[icing]

Hmm, if the server fails to give the account information, mod_md tries to save the account having "unknown" status. That fails as you said due to the security restrictions that are intended. But the failure to save is not acted up.

The validation status for such an account is then ARP_ENOENT, e.g. it does not exist and mod_md will create a new account on renewing a certificate. In cases where the server has an error or a buggy implementation, this will create a new account on each renewal.

Otoh, failing a renewal is the worst kind of thing mod_md is designed for. It is intended to try as hard as it can to get a new certificate.

I see only the possibility of a configuration directive for people who believe in their ACME account and would rather fail renewals than switching accounts. We have lived without that for the last 8 years, so I am not sure this is worth it.

[mkauf]

I agree that a new ACME account is probably OK for most users. I'm not sure whether mod_md really creates a new account in this situation.

I have just found this code, it looks like an infinite loop. acct_find_and_verify() returns APR_EAGAIN if the account exists in the MDStoreDir but could not be validated. But maybe I am missing something.

apr_status_t md_acme_find_acct_for_md(md_acme_t *acme, md_store_t *store, const md_t *md)
{
    apr_status_t rv;
    
    while (APR_EAGAIN == (rv = acct_find_and_verify(store, MD_SG_ACCOUNTS, 
                                                    mk_acct_pattern(acme->p, acme), 
                                                    acme, md, acme->p))) {
        /* nop */
    }

More thoughts:

• Partial bugfix: remove the call to md_acme_acct_save() (to avoid the permissions problem).
• Maybe a workaround for issue SwissSign ACME server rejects POST-as-GET on account URL during renewal (403 Forbidden) #409: try the "faked ToS agreement" also for APR_EACCES (currently only tried for APR_EINVAL)

        if (APR_EINVAL == rv && (acme->acct->agreement || !acme->ca_agreement)) {
            /* Sadly, some proprietary ACME servers choke on empty POSTs
             * on accounts. Try a faked ToS agreement. */

[mkauf]

The infinite loop happens if the CA returns acme:error:userActionRequired as the result of an account update. This error is mapped to APR_EAGAIN by mod_md. (md_acme.c, line 64)

mod_md then sends account update requests again and again.

To test it, apply the patch below to Pebble. After mod_md created the ACME account and got the certificate, delete the certificate from the MDStoreDir, and restart the Apache server.

diff --git a/wfe/wfe.go b/wfe/wfe.go
index 05c6d4c..ad85c15 100644
--- a/wfe/wfe.go
+++ b/wfe/wfe.go
@@ -1084,15 +1084,7 @@ func (wfe *WebFrontEndImpl) UpdateAccount(
 	// if this update contains no contacts or deactivated status,
 	// simply return the existing account and return early.
 	if updateAcctReq.Contact == nil && updateAcctReq.Status != acme.StatusDeactivated {
-		if !postData.postAsGet {
-			wfe.sendError(acme.MalformedProblem("Use POST-as-GET to retrieve account data instead of doing an empty update"), response)
-			return
-		}
-		err := wfe.writeJSONResponse(response, http.StatusOK, existingAcct)
-		if err != nil {
-			wfe.sendError(acme.InternalErrorProblem("Error marshaling account"), response)
-			return
-		}
+		wfe.sendError(acme.UserActionRequiredProblem("Not accepting empty account updates"), response)
 		return
 	}
 

[mkauf]

The infinite loop may also happen if an ACME account has been disabled. In md_acme_acct.c:

           if (APR_STATUS_IS_ENOENT(rv)) {
               /* verification failed and account has been disabled.
                  Indicate to caller that he may try again. */
               rv = APR_EAGAIN;
           }

[icing]

While I am all for making the module more robust, I am not a fan of supporting servers that are not ACME compliant. It's simply not a goal for me.

[mkauf]

I searched for acme:error:userActionRequired, and found this: https://community.buypass.com/t/k9bqnp/account-doesnt-agree-to-current-terms

So BuyPass may return this error code, triggering an endless loop. I don't know if BuyPass is "ACME compliant".

[icing]

Buypass has discontinued certificate issuance as of last summer. https://www.buypass.com/products/tls-ssl-certificates/discontinues-issuance-of-tls-ssl-certificates