Site full domain name: langate.gmsi.com
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 gmsi.com 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 letsencrypt.org 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 gethttpsforfree.com 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?
I donât really know / use the gethttpsforfree.com 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.
Thank you serverco your helpful reply to my request for more information using the gethttpsforfree.com 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 http://pilotonsiteipsec.verisign.com/cgi-bin/pkiclient.exeâ
as an example. I strongly suspect that this will not work with letsencrypt.org.
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 gethttpsforfree.com 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.
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 gethttpsforfree.com page and the zerossl.com wizard attempt. I did what the gethttpsforfree.com 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 gethttpsforfree.com page the zerossl.com 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.
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)
tialaramex you are good! 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 letsencrypt.org is interpreting the use of this subject ID correctly?
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 langate.gmsi.com (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.
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 info.ssl.com article on the Common Name (CN) subject component. It reads:
The Common Name is typically composed of Host + Domain Name and will look like âwww.yoursite.comâ or âyoursite.comâ. 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 âdomain.comâ will receive a warning if accessing a site named âwww.domain.comâ or âsecure.domain.comâ, as âwww.domain.comâ and âsecure.domain.comâ are different from âdomain.comâ. 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 letsencrypt.org is correct and Juniper is wrong! The info.ssl.com
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 zerossl.com 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.
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 zerossl.com 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 gethttpsforfree.com 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 crt.sh registry - crt.sh | langate.gmsi.com 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 crt.sh 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 crt.sh 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 zerossl.com 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 info.ssl.com 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 crt.sh website and proceed to load and activate the letsencrypt.org ssl certificate so 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 zerossl.com 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)?
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 
joy has occurred at long last (the activation procedures in JunOS were not easy, again due to Juniper documentation deficiencies).