Getting a 500 Internal Server Error while trying to set up

Hi,

I thought I’d finally get around to putting a ssl cert on one of my toy sites however I’m not having much luck, I’ve tried 3 different clients (Have skipped certbot so far on account of python issue) but they’re all failing the same way

I tried first on the staging server then on production as a last ditch attempt (in case staging is broken - it always is where I work :D)
Full domain is cryptohash.net
Most recently I ran getssl
Running it against the following subdomains cryptohash.net,md2.cryptohash.net,md4.cryptohash.net,md5.cryptohash.net,sha1.cryptohash.net,sha224.cryptohash.net,sha256.cryptohash.net,sha384.cryptohash.net,sha512.cryptohash.net,ripemd128.cryptohash.net,ripemd160.cryptohash.net,ripemd256.cryptohash.net,ripemd320.cryptohash.net,whirlpool.cryptohash.net,tiger128-3.cryptohash.net,tiger160-3.cryptohash.net,tiger192-3.cryptohash.net,tiger128-4.cryptohash.net,tiger160-4.cryptohash.net,tiger192-4.cryptohash.net,snefru.cryptohash.net,snefru256.cryptohash.net,gost.cryptohash.net,gost-crypto.cryptohash.net,adler32.cryptohash.net,crc32.cryptohash.net,crc32b.cryptohash.net,fnv132.cryptohash.net,fnv1a32.cryptohash.net,fnv164.cryptohash.net,fnv1a64.cryptohash.net,joaat.cryptohash.net,haval128-3.cryptohash.net,haval160-3.cryptohash.net,haval192-3.cryptohash.net,haval224-3.cryptohash.net,haval256-3.cryptohash.net,haval128-4.cryptohash.net,haval160-4.cryptohash.net,haval192-4.cryptohash.net,haval224-4.cryptohash.net,haval256-4.cryptohash.net,haval128-5.cryptohash.net,haval160-5.cryptohash.net,haval192-5.cryptohash.net,haval224-5.cryptohash.net,haval256-5.cryptohash.net

I even renamed all my domains (they used to be underscores not dashes)

Got a reference #179.6cb57568.1474529297.3c20eb

The full output text is way long but this looks like the start of a sub-request

HTTP/1.1 202 Accepted
Server: nginx
Content-Type: application/json
Content-Length: 335
Boulder-Request-Id: 3QBcFfIFf_7Mix13DwufJqVxhIHy2VOlR0a0f90qMco
Boulder-Requester: 4510433
Link: <https://acme-v01.api.letsencrypt.org/acme/authz/A1gbEXYEUCUw7pFVsD_dgClx8eFwvPCy9GbwJAF0jKc>;rel="up"
Location: https://acme-v01.api.letsencrypt.org/acme/challenge/A1gbEXYEUCUw7pFVsD_dgClx8eFwvPCy9GbwJAF0jKc/271270046
Replay-Nonce: ANf9br6wJuSoxCIcB7od5DHhRYdnqooq4gIBnZxhGEQ
Expires: Thu, 22 Sep 2016 07:28:10 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Thu, 22 Sep 2016 07:28:10 GMT
Connection: keep-alive
response {
  "type": "http-01",
  "status": "pending",
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/A1gbEXYEUCUw7pFVsD_dgClx8eFwvPCy9GbwJAF0jKc/271270046",
  "token": "BfzJEP9EZGElEbjD72epd_4zTVQ1Agfyy3VpgpuRuO8",
  "keyAuthorization": "BfzJEP9EZGElEbjD72epd_4zTVQ1Agfyy3VpgpuRuO8.3dds3VAeGTS8X_gd4Fu8mXBrjgFWZkidMfgZdGXtVAI"
}
code 202
checking
url https://acme-v01.api.letsencrypt.org/acme/challenge/A1gbEXYEUCUw7pFVsD_dgClx8eFwvPCy9GbwJAF0jKc/271270046
response {
  "type": "http-01",
  "status": "pending",
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/A1gbEXYEUCUw7pFVsD_dgClx8eFwvPCy9GbwJAF0jKc/271270046",
  "token": "BfzJEP9EZGElEbjD72epd_4zTVQ1Agfyy3VpgpuRuO8",
  "keyAuthorization": "BfzJEP9EZGElEbjD72epd_4zTVQ1Agfyy3VpgpuRuO8.3dds3VAeGTS8X_gd4Fu8mXBrjgFWZkidMfgZdGXtVAI"
}
code
getcr return code 0
Pending
sleep 5 secs before testing verify again
checking
url https://acme-v01.api.letsencrypt.org/acme/challenge/A1gbEXYEUCUw7pFVsD_dgClx8eFwvPCy9GbwJAF0jKc/271270046
response {
  "type": "http-01",
  "status": "valid",
  "uri": "https://acme-v01.api.letsencrypt.org/acme/challenge/A1gbEXYEUCUw7pFVsD_dgClx8eFwvPCy9GbwJAF0jKc/271270046",
  "token": "BfzJEP9EZGElEbjD72epd_4zTVQ1Agfyy3VpgpuRuO8",
  "keyAuthorization": "BfzJEP9EZGElEbjD72epd_4zTVQ1Agfyy3VpgpuRuO8.3dds3VAeGTS8X_gd4Fu8mXBrjgFWZkidMfgZdGXtVAI",
  "validationRecord": [
    {
      "url": "http://ripemd160.cryptohash.net/.well-known/acme-challenge/BfzJEP9EZGElEbjD72epd_4zTVQ1Agfyy3VpgpuRuO8",
      "hostname": "ripemd160.cryptohash.net",
      "port": "80",
      "addressesResolved": [
        "59.167.214.24",
        "2001:44b8:219c:8e00::1"
      ],
      "addressUsed": "59.167.214.24"
    }
  ]
}
code
getcr return code 0
Verified ripemd160.cryptohash.net
remove token from /tmp/acl
Verifing ripemd256.cryptohash.net
domain ripemd256.cryptohash.net has location /tmp/acl
url https://acme-v01.api.letsencrypt.org/acme/new-authz
payload {"resource": "new-authz", "identifier": {"type": "dns", "value": "ripemd256.cryptohash.net"}}
payload64 eyJyZXNvdXJjZSI6ICJuZXctYXV0aHoiLCAiaWRlbnRpZmllciI6IHsidHlwZSI6ICJkbnMiLCAidmFsdWUiOiAicmlwZW1kMjU2LmNyeXB0b2hhc2gubmV0In19
nonce fupznLAdq-Bypnz2wofe5hdrS3Lq3owvzCrZbwDPIno
protected {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "xZlNFky42KaJzagC5-XHXRrMvUY6uGrdmGHkTRh-iQnNG-YIsh7P3gNxcXYLUQbSMDpwrfrWj-Tob5QV7J6vEIhkkOqL3e6CCpDZjn5_tFlh2FQR0JKqu00PyL6s0XnFpptsbPZK97p5PYtyFCWi-IluWsJ_pPFCzM4yMM2R5V4u-Pxbk7unESyFBbjJzi36cI0ENtvrpNu2v0EvRqhn8hpxo6U_kNCf_RcLthIBxDNGp75pevwORaJo7n7opIEUl9gPTeSlG3fclRsmd2ZUjwUIHP6bzDdHB_VmQtIO05tbIUFsYDMynpDA_wIDpwb3IDeq5fq-VuVP5Gj2y326TJx_onSpXjMk3GCzKzd5J7rgbsUe1U4VkiUZgyKimrbjFsEShc3R2j-PJGfkc8dhlgnkGTUZzPe0kX5TYZQdyH-PipNbxndaAwYa-_opxhZGWWgjavGTN7JhgA6xqTx_7oMSD-_NWyVVXc0XU_TUVOq7U5eilZpqD-MOZA6e0bQainOpQFuF6dF8FVv4sO7RKZN5xm4ufsD1NdjhCghFzdeB4rM9Q79m9gcUsGel2AUDsEIWnDBIPTpQyA1Bw1bLa5_liA-CK3v5iSbQMr9tRkYXMTHeEzsVRlKqCcMxrL3TVtupqt05Ncl6dOHhrX6LrRKC22ZGy_wxJzxROZ3_nSU"}, "nonce": "fupznLAdq-Bypnz2wofe5hdrS3Lq3owvzCrZbwDPIno"}
data for account registration = {"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "xZlNFky42KaJzagC5-XHXRrMvUY6uGrdmGHkTRh-iQnNG-YIsh7P3gNxcXYLUQbSMDpwrfrWj-Tob5QV7J6vEIhkkOqL3e6CCpDZjn5_tFlh2FQR0JKqu00PyL6s0XnFpptsbPZK97p5PYtyFCWi-IluWsJ_pPFCzM4yMM2R5V4u-Pxbk7unESyFBbjJzi36cI0ENtvrpNu2v0EvRqhn8hpxo6U_kNCf_RcLthIBxDNGp75pevwORaJo7n7opIEUl9gPTeSlG3fclRsmd2ZUjwUIHP6bzDdHB_VmQtIO05tbIUFsYDMynpDA_wIDpwb3IDeq5fq-VuVP5Gj2y326TJx_onSpXjMk3GCzKzd5J7rgbsUe1U4VkiUZgyKimrbjFsEShc3R2j-PJGfkc8dhlgnkGTUZzPe0kX5TYZQdyH-PipNbxndaAwYa-_opxhZGWWgjavGTN7JhgA6xqTx_7oMSD-_NWyVVXc0XU_TUVOq7U5eilZpqD-MOZA6e0bQainOpQFuF6dF8FVv4sO7RKZN5xm4ufsD1NdjhCghFzdeB4rM9Q79m9gcUsGel2AUDsEIWnDBIPTpQyA1Bw1bLa5_liA-CK3v5iSbQMr9tRkYXMTHeEzsVRlKqCcMxrL3TVtupqt05Ncl6dOHhrX6LrRKC22ZGy_wxJzxROZ3_nSU"}}, "protected": "eyJhbGciOiAiUlMyNTYiLCAiandrIjogeyJlIjogIkFRQUIiLCAia3R5IjogIlJTQSIsICJuIjogInhabE5Ga3k0MkthSnphZ0M1LVhIWFJyTXZVWTZ1R3JkbUdIa1RSaC1pUW5ORy1ZSXNoN1AzZ054Y1hZTFVRYlNNRHB3cmZyV2otVG9iNVFWN0o2dkVJaGtrT3FMM2U2Q0NwRFpqbjVfdEZsaDJGUVIwSktxdTAwUHlMNnMwWG5GcHB0c2JQWks5N3A1UFl0eUZDV2ktSWx1V3NKX3BQRkN6TTR5TU0yUjVWNHUtUHhiazd1bkVTeUZCYmpKemkzNmNJMEVOdHZycE51MnYwRXZScWhuOGhweG82VV9rTkNmX1JjTHRoSUJ4RE5HcDc1cGV2d09SYUpvN243b3BJRVVsOWdQVGVTbEczZmNsUnNtZDJaVWp3VUlIUDZiekRkSEJfVm1RdElPMDV0YklVRnNZRE15bnBEQV93SURwd2IzSURlcTVmcS1WdVZQNUdqMnkzMjZUSnhfb25TcFhqTWszR0N6S3pkNUo3cmdic1VlMVU0VmtpVVpneUtpbXJiakZzRVNoYzNSMmotUEpHZmtjOGRobGdua0dUVVp6UGUwa1g1VFlaUWR5SC1QaXBOYnhuZGFBd1lhLV9vcHhoWkdXV2dqYXZHVE43SmhnQTZ4cVR4XzdvTVNELV9OV3lWVlhjMFhVX1RVVk9xN1U1ZWlsWnBxRC1NT1pBNmUwYlFhaW5PcFFGdUY2ZEY4RlZ2NHNPN1JLWk41eG00dWZzRDFOZGpoQ2doRnpkZUI0ck05UTc5bTlnY1VzR2VsMkFVRHNFSVduREJJUFRwUXlBMUJ3MWJMYTVfbGlBLUNLM3Y1aVNiUU1yOXRSa1lYTVRIZUV6c1ZSbEtxQ2NNeHJMM1RWdHVwcXQwNU5jbDZkT0hoclg2THJSS0MyMlpHeV93eEp6eFJPWjNfblNVIn0sICJub25jZSI6ICJmdXB6bkxBZHEtQnlwbnoyd29mZTVoZHJTM0xxM293dnpDclpid0RQSW5vIn0", "payload": "eyJyZXNvdXJjZSI6ICJuZXctYXV0aHoiLCAiaWRlbnRpZmllciI6IHsidHlwZSI6ICJkbnMiLCAidmFsdWUiOiAicmlwZW1kMjU2LmNyeXB0b2hhc2gubmV0In19", "signature": "cAHGCGkk6lUB2MPfmLB_aPrRc-3BWJDsqkYFeWsT9wv-b3NsCJCFa-VAeZjjDCrqv_aD85KSaJK3-8lVz9Q2nby7zPvQjYiHC4nwMZw1xADhRiiGcE0ejxjoH3dHfB7VVxtlCdVHdLdm6KyBse8T1uhBPjGbgUwXiJLre5eHV-8e_JV6MCYjjYxTlMQMMjGUHSIEid6yzPxryLEu3TFN68Hd4rF7esY2wGuWeqzvii2D5UuWizZL9JbnOOE33M4c_MyO1zp4d2O2gOTOkYt9Gm2FrT0EnsX7F_3TOLs_QUa884MG3WO6SNT280tUmTdnFPTHfw8k2sNWxgsqmF6Q3-Gll-EbczJkPZgGcsRdoy0W25gc2Q5M8Y2LvSZy0Pce7Okcbrdo9cD3PPhp_A55ET_z1WWG3fQ91k6lwt3go5BXxL2u_BsRVKAh8n6y0nxsZtyf-ZiLsyO3YtoGyL5u3u3K6CyqsnUSCLoqQln2c-8OmSyGV_YApCVlm678bmme26oP2qXGkBQtEdWKRchjrhF2QhLofH6xRncJfRAZlf8PX1kMHAmI6QCth3D1P7XoYVakW67_6Nj_PZehIXN0Euzc8vuCYyzG0eKUcilrBg3KiOxsahLimfupl4znloUhlbQgIi8eBDAyFSGRV83JnN6bJqJeBA4J-eWhop7YPO0"}
responseHeaders HTTP/1.1 100 Continue
Expires: Thu, 22 Sep 2016 07:28:17 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 500 Internal Server Error
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Content-Length: 175
Expires: Thu, 22 Sep 2016 07:28:17 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Thu, 22 Sep 2016 07:28:17 GMT
Connection: close
response <HTML><HEAD><TITLE>Error</TITLE></HEAD><BODY>
An error occurred while processing your request.<p>
Reference&#32;&#35;179&#46;6cb57568&#46;1474529297&#46;3c20eb
</BODY></HTML>
code 500
completed send_signed_request
getssl: new-authz error: <HTML><HEAD><TITLE>Error</TITLE></HEAD><BODY>
An error occurred while processing your request.<p>
Reference&#32;&#35;179&#46;6cb57568&#46;1474529297&#46;3c20eb
</BODY></HTML>

You have a good few subdomains there :slight_smile:

Can you put the full debug on pastebin, or email me “getssl at serverco.com” (I wrote the GetSSL script ) and I’ll take a more detailed look at it for you … that looks (oddly) like an error from the ACME server at first glance.

Well, they said I could have 100 subdomains :smiley:

Email is on it’s way, I don’t think it’s your script mostly because I get the same error with other scripts, I just thought “meh, broken, unmaintained” and moved on.

But, I could be wrong, that’s why I came here not github :slight_smile:

you can :slight_smile:

I have seen the occasional error like that over the past day - but with typically only 2 or 3 subdomains per cert I've just re-run the script when getting that error and it's been fine.

I've just created a version of the code which checks for that error on the ACME server though, and loops and retrys ( rather than failing ) - so should make GetSSL more resilient.

If you can update GetSSL to v1.44 ( the command “getssl -u” should do it ) - and try again please - it should hopefully be a good test at least.

I’d keep testing on the “staging” server, for now as we don’t want you to hit rate limits :wink:

Trying it now, might I suggest a short sleep before retry?
And maybe a retry limit? I wouldn't want to leave this hammering them for hours....

I agree totally - was about to do that, just wanted to give you a version to test ( I did check on my boxes first that it worked OK … but I wasn’t getting lots of the 500 error )

Still getting the odd 500, seems to be working most times on the second try.

OK, that’s good - adding a short delay ( and a limit) as you suggest. good to know it seems to be going in the right direction though.

Seems to have completed ok

        X509v3 Subject Alternative Name:
            DNS:adler32.cryptohash.net, DNS:crc32.cryptohash.net, DNS:crc32b.cryptohash.net, DNS:cryptohash.net, DNS:fnv132.cryptohash.net, DNS:fnv164.cryptohash.net, DNS:fnv1a32.cryptohash.net, DNS:fnv1a64.cryptohash.net, DNS:gost-crypto.cryptohash.net, DNS:gost.cryptohash.net, DNS:haval128-3.cryptohash.net, DNS:haval128-4.cryptohash.net, DNS:haval128-5.cryptohash.net, DNS:haval160-3.cryptohash.net, DNS:haval160-4.cryptohash.net, DNS:haval160-5.cryptohash.net, DNS:haval192-3.cryptohash.net, DNS:haval192-4.cryptohash.net, DNS:haval192-5.cryptohash.net, DNS:haval224-3.cryptohash.net, DNS:haval224-4.cryptohash.net, DNS:haval224-5.cryptohash.net, DNS:haval256-3.cryptohash.net, DNS:haval256-4.cryptohash.net, DNS:haval256-5.cryptohash.net, DNS:joaat.cryptohash.net, DNS:md2.cryptohash.net, DNS:md4.cryptohash.net, DNS:md5.cryptohash.net, DNS:ripemd128.cryptohash.net, DNS:ripemd160.cryptohash.net, DNS:ripemd256.cryptohash.net, DNS:ripemd320.cryptohash.net, DNS:sha1.cryptohash.net, DNS:sha224.cryptohash.net, DNS:sha256.cryptohash.net, DNS:sha384.cryptohash.net, DNS:sha512.cryptohash.net, DNS:snefru.cryptohash.net, DNS:snefru256.cryptohash.net, DNS:tiger128-3.cryptohash.net, DNS:tiger128-4.cryptohash.net, DNS:tiger160-3.cryptohash.net, DNS:tiger160-4.cryptohash.net, DNS:tiger192-3.cryptohash.net, DNS:tiger192-4.cryptohash.net, DNS:whirlpool.cryptohash.net
        X509v3 Certificate Policies:

I have the full log (594k) if you want it?

Seems odd that this interface doesn’t support batching?

Great, glad that at least got round the issue ( and helped make GetSSL more resilient - thanks )

I don't need the full log, that's fine.

The cert you have will be identical to a real one (assuming you used the staging server ), but issued by "fake Let's Encrypt", it's worth testing on one of the domains at least - then changing from the staging server to the real CA server to get a real cert.

Which interface ? You mean that GetSSL checks one subdomain at a time and verifies it ?

Yeh that one, I guess there's pros and cons of doing it in a batch too.

I wrote it for myself initially - mainly to run remotely, upload the tokens and certs, for servers / routers etc which wouldn’t run the official client, and most of those devices only had one or two domain names… hence done in a linear manner.

In reality - it’s run in a cron once set up, so it makes very little difference, it’s not like you’re watching it. Let’s Encrypt also remembers which domains have already been verified ( by default … for 90 days currently ) … so it doesn’t need to re-verify them, and will issue a renewal cert pretty quickly.

No that’s ok, I just assumed the letsencrypt interface wouldn’t take multiple domains for batch verification.

Now I’m doing some reading into dns based verification, that could be fun to set up too :smiley:

Thanks so much for your help

You’re Welcome :slight_smile:
Have fun - the DNS stuff is nice - just need to write a script to add / remove the TXT records from your DNS, and all good to go :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.