HTML CSR page fails at Step 3 with "Error: Account registration failed. Please start back at Step 1. { "type": "urn:acme:error:malformed", "detail": "JWS verification error", "status": 400 }"

Site full domain name:
Successfully ran all commands in Steps 1 & 3 as specified and pasted output into designated fields.
The command output was correct as anticipated in the examples.
Web server is Juniper SRX240 firewall running heavily customized version of BSD Unix.
Site is only node on ISP DMZ.

The firewall system provides structured CLI commands for generating PKI public/private key pairs (2048 bit RSA) as well as the CSR but no access to an openssl utility and there is no way to use any of the automated CA-Cert utilities provided by using this platform. Therefore the openssl tool (1.0.2g-1ubuntu4.2) in Ubuntu Linux 16.04 is used to prepare the input necessary to obtain the CA-Cert using the web page. The Step 1 public RSA key is supplied from Ubuntu openssl and the Step 2 CSR pasted from the SRX240 are all accepted (the “Validate CSR” reads the data and finds the domains and CN) but the Step 3 “Validate Signatures” using the Ubuntu private key associated with the public key provided in Step 1 fails with: “Error: Account registration failed. Please start back at Step 1. { “type”: “urn:acme:error:malformed”, “detail”: “JWS verification error”, “status”: 400 }”.

Since the malformation data that is causing this error is not provided, it is impossible to determine how to get past the Step 3 error. Could it be that the four signing requests in Step 3 require the same public and private keys that were used to generate the CSR as shown in the instructions for Step 2? If so, why would the commands in Step 3 specify the key generated for the account in Step 1? Why is it necessary to issue the “openssl genrsa 4096” command twice, once for the account and again for the domain? Why is the account key from Step 1 not used to generate the CSR in Step 2 when the two commands are otherwise identical except for the filename used to save their output?

Thank you for your attention to these questions.

I don’t really know / use the system - and normally suggest checking with the clients author, but there doesn’t appear to be a help page associated with it as far as I can see.

Personally I’d suggest using one of the other alternate clients - which I think would suit your situation much better as they can be automated (rather than a manual process every couple of months).

If you have a DNS provider who has an API for the DNS ( from a quick look, you use your own DNS, so should be relatively easy), I’d suggest using one of the Bash or Go clients, as these all support the DNS challenge for obtaining a certificate ( basically you add a TXT record to your DNS for authorisation).

If you can’t use the DNS challenge easily, then I’d suggest the GetSSL client (although I’ll admit to bias, as I wrote it) - since this is designed to run on one machine ( your ubuntu linux) and, providing you have ssh, sftp access will automatically place the tokens ( and certs) onto another box (such as your Juniper firewall). Some of the Bash clients may even run on your customized BSD firewall if you wanted to.

1 Like

Thank you serverco your helpful reply to my request for more information using the webpage. The reason I am attempting to obtain a ca-cert with that interface is that I’m pretty certain (without, of course, diving into all the code) that none of the scripts available for unix systems will function because they will inevitably depend on utilities that either are not provided or work differently than those assumed in the scripts. Juniper does provide a CLI command to obtain a ca-cert, specifically:
'request security certificate enroll filename ca_verisign ca-file verisign ca-name xyzcompany url
as an example. I strongly suspect that this will not work with
The DNS solution sounds intriguing but, even though we have an API to manipulate our zone configuration, it is actually a hosted DNS servicing our domain. I will, of course, continue to work on the problem in the absence of complete documentation and also take a closer look at the alternate clients provided as you suggest.

If anyone else out there has experience with and knows what might cause the Step 3 error, I would greatly appreciate your comments and/or suggestions. I suspect it does work but I’ve made an incorrect assumption or two.

You can try ZeroSSL clients - either online Certificate Wizard (no need to install anything), or the installable package (in Perl). Both support HTTP and DNS verification.

Regarding this:

From the security standpoint you should not be using the same key for the account as for the domain certificate. And if I'm not mistaken, it is additionally verified on the LE side and an error will be returned if you try.

Thanks leader for your advice here. Effectively there are two different keys being used for the account and for the domain (the CSR was generated by the target host having generated its own public/private key pair and the account key was created as instructed using the openssl tool in Ubuntu Linux). So, that certainly should not be the cause for the error in Step 3. I’ll try your suggested URI and see if I get any different results.

Here is an update on both the page and the wizard attempt. I did what the page Step 3 error stated and this time received a different error:
"Error: Domain failed. Please start back at Step 1. { “type”: “urn:acme:error:malformed”, “detail”: “Invalid character in DNS name”, “status”: 400 }"
So it doesn’t look like that is going to work. So I tried the wizard and it rejected my openssl generated rsa public key as invalid. The wizard offers to generate one for you so I blanked out the key field in the form and pressed “Next.” It took about a minute or so to generate a private/public key pair that it put in the field and told me to copy/paste it or download it (I did both just to be sure I got it right). Then I pressed “Next” again after selecting the DNS verification and accepting both the TOS and SA. After a moment I received the following error:
"Certificate failure

Unfortunately there was an error while receiving your Free SSL Certificate. Please try again later - if error still persists, then let us know and we will try our best to sort this out.

Error information: Error creating new cert :: policy forbids issuing for: it admin."

So, it would appear that I will need to try again later, however, I don’t believe that whatever policy problem caused the error will be resolved by simply trying again. Like the page the wizard provides very few instructions about specifically what is needed to successfully issue certificates or what to do if an error occurs.

The JunOS command listed earlier is for a protocol called SCEP which Let’s Encrypt does not offer although I suppose that in some cases companies could build a SCEP proxy which used DNS challenges to get certificates from Let’s Encrypt and then hand them out over SCEP.

However JunOS should also have other ways to help you get where you need to go. I will look at this more thoroughly when I’m at a keyboard not on my phone.

1 Like

Sorry, still on a train far from keyboards. However this text…

“policy forbids issuing for: it admin.”

… is probably from Let’s Encrypt itself. It suggests Let’s Encrypt believes you are asking for a certificate with these names, not (just) for the name you listed at the top of your original post. It cannot sign such names, only Fully Qualified Domain Names from the public Internet DNS may appear in end user certificates from Let’s Encrypt.

Instructions for systems like your Juniper often suggest very flowery X.500 Distinguished Names can be used in certificates. Home grown certificates are certainly free to do this, but Let’s Encrypt is obliged to sign only facts it has verified, and the only fact it verifies is your FQDNs. It should mostly just ignore other stuff, skipping over it entirely - but if you claim a Common Name, that will need to be an FQDN (and next of course Let’s Encrypt will need to see proof it’s yours)

1 Like

tialaramex you are good! :smile: Very interesting! The JunOS CSR generator provides two fields for domain information the DC (Domain Component) and the “domain-name” which is in the certificate extensions and should contain a fully qualified Domain Name. The CSR I provided to both web interfaces is correctly populated with both fields that should be verifiable from any Internet Connected host. Juniper shows the CN (Common Name) field containing “John Doe” in their CSR generator examples. I chose to put “IT Admin” in there instead corresponding to the “email” certificate extension and my “Account E-mail” field in both web based CSR interfaces. There isn’t even a hint anywhere that the CN field would be checked against the DNS! Are you sure that is interpreting the use of this subject ID correctly?

policy forbids issuing for: it admin.

That message indeed comes directly from LE servers. ZeroSSL can generate the CSR for you (when you specify the domains list) or it can use whatever CSR you already have. Since the message quotes something different than (says "it admin"), I imagine that is the latter and this is the CSR you have created on your device. In that case you would need to look into how to specify correct name while generating a CSR there.

1 Like

Ok, leader and tialaramex your comments have helped I think what will be the resolution to the issue. It appears both CSR submission sites are reacting to the same problem–specifically, the Juniper JunOS documentation and examples are entirely misleading when it comes to generating CSRs that can provide functional SSL Certificates. I just read the article on the Common Name (CN) subject component. It reads:

Understanding the Common Name
Before you can enroll for a SSL Server Certificate, you must generate a CSR from your webserver software. During the creation of the CSR, the following fields must be entered: Organization (O), Organizational Unit (OU), Country ©, State (S), Locality (L), and Common Name (CN). The Common Name field is often misunderstood and is filled out incorrectly.

The Common Name is typically composed of Host + Domain Name and will look like “” or “”. SSL Server Certificates are specific to the Common Name that they have been issued to at the Host level. The Common Name must be the same as the Web address you will be accessing when connecting to a secure site. For example, a SSL Server Certificate for the domain “” will receive a warning if accessing a site named “” or “”, as “” and “” are different from “”. You would need to create a CSR for the correct Common Name. When the Certificate will be used on an Intranet (or internal network), the Common Name may be one word, and it can also be the name of the server.

I’m convinced that is correct and Juniper is wrong! The
article also indicates I need to change my Locality (L) entry as well. I will revoke the existing CSR and generate a new one with the fields corrected as per this discussion.
Thanks to both of you for your able assistance.

Suggestion: It might help to have a page of instructions accessible from your front page that unambiguously describes all the fields that are critical to generating functional certificates from the LE service with examples on what they should contain.

The saga continues. I revoked the previous CSR and created a new one with fields as indicated above. Indeed, I got much further this time–all the way to entering the DNS TXT record challenge and verifying that it was there with the ‘host -tTXT’ command. I then confidently clicked Next in the wizard only to be served with:

"Certificate failure

Unfortunately there was an error while receiving your Free SSL Certificate. Please try again later - if error still persists, then let us know and we will try our best to sort this out.

Error information: Error creating new cert."

So (I’m only guessing) there might be something wrong now with the LE servers that would be expected to clear up later by itself? (I must admit that “Error creating new cert.” wouldn’t be any more helpful to you than it is to me.) Thanks for all your help so far. I’ll go ahead and try this again tomorrow–significant progress was made today (although I still don’t have my cert).

Let’s Encrypt won’t include your Locality in any certificate it issues anyway, it can’t verify that your answer was true so it mustn’t sign saying it did.

The Common Name was a problem because Let’s Encrypt wants to include that but the answer you gave was impermissible. For C, L, O and so on it’ll just throw away your answers.

1 Like

Thanks tialarmex for that info–again I had no way to know what was or was not included in the certificate. You may be interested to know that, using the public/private keys that were created by the wizard and registered with Lets Encrypt once I got past the CN problem, I was able to get the static page to go all the way through Step 4. The problem is the python2 command won’t run in JunOS and I am going to have to reconfigure the firewall at least temporarily to get it to serve up that challenge page they require (gethttpsforfree doesn’t offer DNS TXT record verification). It is possible but a lot of work to reconfigure the JunOS web service for just that momentary verification step (port 80 is filtered and everything is hidden in strange places). So I’m going to try the wizard again tomorrow and see what happens–maybe I didn’t wait long enough for it to succeed in resolving the TXT record (it worked here locally but I’m not sure where the LE server would have been querying from and how zone file changes might propagate).

Well, actually there is a "Learn More" link for each tool on ZeroSSL describing the process. As for the fields that are critical - effectively just correctly filled CN would be enough usually. CSR with missing OU, Locality, etc is still processed by LE just fine. There was just one outstanding issue with some devices which would flag some extensions on CSR as critical, making LE servers to reject that.

I do believe that you have actually succeded with issuing the certificate, according to registry - | The error ZeroSSL shows usually indicates that there is a temporary issue preventing your browser from accessing LE endpoints (say maintenance or networking issues). You can copy the certificate from or try again this evening and see if it works this time (if you use the same LE key and CSR on the Details step as you used originally, you will not need the verification step - you should be taken straight to the Certificate).

If you are still experiencing an error this evening, please use the contact form on ZeroSSL and I will try to help you directly.

Thank you leader for the additional information provided above. I checked the “Learn More” button on the zerossl page and it doesn’t say what you do above about the CN field being critical to acceptance of CSRs. However, I did go to the site and am encouraged to see that a cert is registered according to our CSR. I just tried the zerossl wizard again and it did behave as you described (after entering the 4096bit key and CSR blocks and checking off the DNS and accepting the TOS and SA it did take me directly to the certificate stage but again was served with:
"Certificate failure

Unfortunately there was an error while receiving your Free SSL Certificate. Please try again later - if error still persists, then let us know and we will try our best to sort this out.

Error information: Error creating new cert."

I will now take it up with zerossl support and see what they say.
Thanks again for everyone who helped with this.

Well, it could be outlined that for pre-made CSR the CN field is crtitical. The client however makes sure that names are present on the CSR anyway and should show an error message if they aren’t, so it is not so much a problem of having or not having something in CN/SAN rather than an issue of it’s being invalid. It is likely that a stricter check will be added for that.

Regarding the error, I will look into that, but please submit a query via site as well - it will be easier to get to the root of the issue by communicating directly.

Thanks leader for your reply. Having been thoroughly misled by the Juniper CSR documentation, the error was nearly a complete mystery (there is simply no indication that the CN field is critical to the ca-cert verification and certification process–as indicated, the was extremely helpful. You might even provide a link on your page to their site.

At your suggestion, I was able do download the ca-cert from the website and proceed to load and activate the ssl certificate so :grinning: joy has occurred at long last (the activation procedures in JunOS were not easy, again due to Juniper documentation deficiencies).

I did report the problem to the support site and they have already followed up. They admitted that it was an unusual and perplexing response being that everything else was successful so they are already working on it. Thanks again to everyone who contributed.

I believe we have found the root cause of that error. It seems that if SAN contains not only the domain name but also records of other types (such as email or IP in this case), LE server fails with “Internal server error” and “Error creating new cert” response without giving any additional details. Once those records are removed, the error goes away.

@schoen, could you please confirm if that’s a known issue and what kind of fix might be in the works (such as ignoring invalid entries for example and proceeding or returning some meaningful response regarding as to why the CSR is getting rejected)?