It produced this output:
Certificate signature failed. If you supplied your own CSR make sure the domains on it match what you put on SSLForFree. If there is a rate limiting error at the end of this paragraph certificates per Domain is currently 5 per 7 days. Try asking Lets Encrypt to increase the limit or wait 7 days. Rate limits should increase in the near future. { “type”: “urn:ietf:params:acme:error:badPublicKey”, “detail”: “Error finalizing order :: invalid public key in CSR: error checking blocklist for key: \u0026{{18111848663142005571178770624881214696591339256823507023544605891411707081617152319519180201250440615163700426054396403795303435564101919053459832890139496933938670005799610981765220283775567361483662648340339405220348871308593627647076689407931875483406244310337925809427432681864623551598136302441690546585427193224254314088256212718983105131138772434658820375111735710449331518776858786793875865418124429269409118756812841019074631004956409706877081612616347900606555802111224022921017725537417047242635829949739109274666495826205002104010355456981211025738812433088757102520562459649777989718122219159982614304359 19689526866605154788513693571065914024068069442724893395618704484701 2859278237642201956931085611015389087970918161297522023542900348087718063098423976428252369340967506010054236052095950169272612831491902295835660747775572934757474194739347115870723217560530672532404847508798651915566434553729839971841903983916294692452760249019857108409189016993380919900231322610083060784269299257074905043636029708121288037909739559605347853174853410208334242027740275688698461842637641566056165699733710043802697192696426360843173620679214131951400148855611740858610821913573088059404459364892373027492936037789337011875710759208498486908611261954026964574111219599568903257472567764789616958430} 13708884834655530397676506653173405555394812073443875272547390643438895423336604601253605619088649939928016231827347450149276236007324918902630135687214308805395163459853017623730111143665317967249154015554291981831721825133634978099863836402587971520327608955283357580703191620825174565898258824741358927705280607697038018628631987146872264723046311902284927765264379773883241464216145365565073374771897925119972686917063519230365982498050912958533087740677326641022473818382538666688717432565184365429559778836645450871914868590377163373826447854768381257416916643600145770267244671698121699549704404454467361381802}”, “status”: 400 }
My web server is (include version): generic tomcat
The operating system my web server runs on is (include version): its implementation detail I wont offer to public.
My hosting provider, if applicable, is: its implementation detail I wont offer to public.
I can login to a root shell on my machine (yes or no, or I don’t know): its implementation detail I wont offer to public.
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): its implementation detail I wont offer to public.
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): I do not use certbot.
Description: I used a CSR to create a certificate having multiple SANs. Since the CSR is only parsed maleformated (CSR classically have -----BEGIN NEW CERTIFICATE REQUEST----- in first line and -----END NEW CERTIFICATE REQUEST----- as last line what is well-formated) due to a bug in the language go, the CSR is rejected, no certificate is created but the domains are added to a blocklist and rejected during a second try (rejected by line https://github.com/letsencrypt/boulder/blob/master/goodkey/good_key.go#L85 ).
Please
Remove the domains from the blocklist
Fix the maleformated-only CSR parsing
Do not add domains to the blocklist if no certificate is generated
In order to better understand the problem, and as a CSR file is essentially a public document, please post the CSR file used here.
[CSR files contain no private information]
The blocked keys list is (currently) statically defined during the runtime of Boulder. Nothing you do can alter its state.
I don't think that there is a PEM-parsing bug.
We can see that the CSR was already at least parsed through the PEM form, because the raw bigint values of the public key are reported. Only way to get here is if we already went from PEM -> DER -> ASN.1 -> struct representation.
I agree with @rg305 , could you post the CSR please (or a different throwaway one)?
I think the issue might be your CSR’s common name section.
I believe when Let’s Encrypt and other CAs check for Domain certificates, they are expecting Common Name and SAN lists to contain only valid hostnames. You have a name in your common name, which isn’t accepted for Domain certificates. (Might be acceptable for S/MIME or other signing certificates?)
Do not add domains to the blocklist if no certificate is generated [REMAINS_OPEN]
Is that correct?
Furthermore I do like to add a feature-request:
Improve documentation: If you check "I have CSR" a message appear telling "Make sure your CSR has all the domains specified above otherwise it will only make the SSL certificate with the domains specified in the CSR.". This message means nothing to people who know what a CSR contains. It is good for people who have no experience with CSR like Managers and innocent people. I do like to suggest an additional phrase:
Please check the CSR to have your SubjectPublicKey matches our DV-SSL End Entity Certificate requirements.
CSR is invalid. Make sure to disable all extensions but SAN on your CSR as any other extensions are not supported. Full error: { "type": "urn:ietf:params:acme:error:malformed", "detail": "Error parsing certificate request: asn1: structure error: tags don't match (16 vs {class:0 tag:4 length:65 isCompound:false}) {optional:false explicit:false application:false private:false defaultValue:\u003cnil\u003e tag:\u003cnil\u003e stringType:0 timeType:0 set:false omitEmpty:false} certificateRequest @2", "status": 400 }
What's wrong is that sslforfree doesn't like the type label in the PEM header:
and
The word NEW should not be there, it should just be e.g.:
-----BEGIN CERTIFICATE REQUEST-----
What seems to be happening is the extra word is causing sslforfree to screw up its encoding of the JWS in the finalization step of the order.
If you get rid of NEW, everything should work.
According to RFC 7468 - Textual Encodings of PKIX, PKCS, and CMS Structures , all generators must use the CERTIFICATE REQUEST label, so the tool you used to create the CSR is out of spec. It also says that parsers may treat NEW CERTIFICATE REQUEST as being equivalent, so maybe you can report this as a bug to info@sslforfree.com .