ACME Certificate on EMS server - EMS Invalid certificate and private key: argument 'data'

Yes. The error strongly suggests one of two things, and the first is more likely:

Most likely

EMS 7.4.5 has an ACME handling bug or parsing defect, not a normal Let’s Encrypt validation failure.

Why I say that:

• Fortinet’s documented ACME renewal failures for EMS are usually about ports 80/443, Apache binding on 443, geo-blocks, or inspection interfering with ACME validation. Those failures produce normal ACME errors such as renewal failure or insufficient authorization, not a Python-style type-conversion message about str vs bytes.

• Your error text, Cannot convert "<class 'str'>" instance to a buffer. Did you mean to pass a bytestring instead?, looks like an internal parsing/encoding problem while EMS is processing the certificate/key material, not like a network validation problem from Let’s Encrypt.

The other realistic cause

If EMS is trying to ingest a private key that it cannot parse cleanly, you can get a generic “Invalid certificate and private key” style failure. Fortinet explicitly documents that EMS does not support passphrase-protected private keys. Those must be decrypted first.

With ACME, that usually should not happen from user input directly, but if EMS stores or reuses key material in an unexpected format, the same class of parsing failure is plausible.

What to check first

Do these in this order:

1. Check basic ACME prerequisites anyway

Even though your error does not look like a pure reachability problem, still verify:

• TCP 80 and 443 inbound to EMS are open

• TCP 80 and 443 outbound from EMS are open

• Nothing else is binding to 443

• Restart the EMS Apache service and test again

Fortinet’s EMS ACME article explicitly calls out ports 80/443 and Apache binding on 443 as required for renewal.

2. Check EMS logs immediately after reproducing

On EMS, inspect the ACME / application logs under:

• /var/log/forticlientems/fcm on Linux EMS, per Fortinet’s troubleshooting article

You are looking for the full traceback around the failure. The GUI popup is too generic.

3. Assume 7.4.5 may simply be bad here

Fortinet has release notes for EMS 7.4.5 and newer 7.4.6, which means there is already a later maintenance build available in the same train.

So the practical answer is:

If this started on 7.4.5, test on 7.4.6 or open a TAC case immediately.
This does not look like a normal operational misconfiguration alone.

4. If you imported any custom cert/key before, verify the key format

If there is any manual cert handling involved anywhere in the chain:

• ensure the private key is not passphrase-protected

• ensure it is valid PEM

• ensure cert and key actually match

Fortinet explicitly says EMS does not support passphrase-protected private keys.

My direct assessment

This error is not a standard ACME challenge failure.
It looks like EMS 7.4.5 mishandling certificate/key data internally, with a smaller chance that EMS is encountering unsupported or malformed key material.

What I would do

• verify ports and binding

• pull the full EMS log traceback

• move off 7.4.5 to the next maintenance release in that branch

• if it still fails, open TAC and attach the traceback

The blunt version: this smells like a software defect much more than a misconfiguration.

Hey - I acctually have exactly same issue. And I can confirm it is a bug on 7.4.5 -> when I did upgrade EMS to 7.4.5 after few days later ACME cert should renew and it failed. 

I have opened ticket to TAC and they send me this:


"It is actually fixed now in the attached EMS 7.4.5 hotfix (forticlientems_7.4.5.2111_hotfix_package_2_amd64.zip). -hotfix installation instructions: https://docs.fortinet.com/document/forticlient/7.4.5/ems-cli-reference/968551/execute-hotfix ***Before any version upgrade or other maintenance, back up the EMS database. Consider performing a full server backup or taking a VM snapshot if possible*** Wish you a nice day!"


I

Hi,

This error usually indicates that EMS is receiving the certificate or private key in an unexpected format. Instead of a byte string, it's processing it as a regular string, which can happen if there's an issue with the ACME response, the certificate parsing process, or the private key format.

A few things you can check:

• Verify that the ACME account and challenge validation are completing successfully.

• Ensure the private key and certificate are in a supported PEM format and haven't been modified.

• Check the EMS logs around the time the renewal fails for any additional traceback or ACME-related errors.

• If possible, try generating a new key pair and requesting a fresh certificate to rule out a corrupted key.

If the issue persists, could you share:

• Which ACME provider you're using (e.g., Let's Encrypt)?

• Whether this is a renewal of an existing certificate or a brand-new request?

• Any relevant log entries from the EMS server around the failure?

That information should help narrow down the root cause. 898a