Deserialization error: Wrong directory fields

[zenhack]

Issue by gionn
Monday Nov 28, 2016 at 13:35 GMT
Originally opened as kuba/simp_le#118

---

It looks like that a new staging API as broken simp_le:

       ---- Begin output of simp_le  -d kitchen-test.cloudesire.com:/usr/share/nginx/www/kitchen-test.cloudesire.com_kitchen-test-2.cloudesire.com  -d kitchen-test-2.cloudesire.com:/usr/share/nginx/www/kitchen-test.cloudesire.com_kitchen-test-2.cloudesire.com  --email dev@cloudesire.com --server https://acme-staging.api.letsencrypt.org/directory --tos_sha256 6373439b9f29d67a5cd4d18cbc7f264809342dbf21cb2ba2fc7588df987a6221 -f key.pem -f fullchain.pem -f account_key.json ----
       STDOUT: 
       STDERR: 2016-11-28 11:48:39,389:INFO:simp_le:1211: Generating new account key
       Traceback (most recent call last):
         File "/root/.letsencryptvenv/local/lib/python2.7/site-packages/simp_le.py", line 1401, in main
           return main_with_exceptions(cli_args)
         File "/root/.letsencryptvenv/local/lib/python2.7/site-packages/simp_le.py", line 1386, in main_with_exceptions
           persist_new_data(args, existing_data)
         File "/root/.letsencryptvenv/local/lib/python2.7/site-packages/simp_le.py", line 1282, in persist_new_data
           client = registered_client(args, existing_data.account_key)
         File "/root/.letsencryptvenv/local/lib/python2.7/site-packages/simp_le.py", line 1224, in registered_client
           client = acme_client.Client(directory=args.server, key=key, net=net)
         File "/root/.letsencryptvenv/local/lib/python2.7/site-packages/acme/client.py", line 63, in __init__
           self.net.get(directory).json())
         File "/root/.letsencryptvenv/local/lib/python2.7/site-packages/acme/messages.py", line 169, in from_json
           raise jose.DeserializationError(str(error))
       DeserializationError: Deserialization error: Wrong directory fields

current staging https://acme-staging.api.letsencrypt.org/directory

{
  "key-change": "https://acme-staging.api.letsencrypt.org/acme/key-change",
  "new-authz": "https://acme-staging.api.letsencrypt.org/acme/new-authz",
  "new-cert": "https://acme-staging.api.letsencrypt.org/acme/new-cert",
  "new-reg": "https://acme-staging.api.letsencrypt.org/acme/new-reg",
  "revoke-cert": "https://acme-staging.api.letsencrypt.org/acme/revoke-cert"
}

current prod https://acme-v01.api.letsencrypt.org/directory

{
  "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",
  "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",
  "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",
  "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"
}

[zenhack]

Comment by gionn
Monday Nov 28, 2016 at 13:48 GMT

---

Looks like that kuba/simp_le#112 fix this.

@kuba is this project dead?

[zenhack]

Comment by amiryal
Monday Nov 28, 2016 at 13:52 GMT

---

@gionn see later discussion in kuba/simp_le#114 – seems dead to me, sadly. :(

[zenhack]

Comment by zenhack
Saturday Dec 10, 2016 at 19:42 GMT

---

So it came time today to update my certs, and I banged into this. I've applied #112 and #114 to master on my fork. Right now keeping this tool basically working is the easiest solution for my systems, so I'm happy to maintain it there for the time being. I'll try to be responsive to prs and breaking issues like this, at the very least.

[zenhack]

Comment by zenhack
Saturday Dec 10, 2016 at 19:42 GMT

---

//cc @Thor77

[zenhack]

Comment by backbohne
Monday Dec 12, 2016 at 10:11 GMT

---

Just tested zenhack's fork, but it seems that upgrading the acme module to 0.8 will fire #73 again.

[zenhack]

Comment by zenhack
Monday Dec 12, 2016 at 16:28 GMT

---

@backbone, it works fine on my end. #73 was closed because it was (apparently) a symptom of mixing venv and system packages, how are you installing it?

[zenhack]

Comment by joshmanders
Monday Dec 12, 2016 at 19:34 GMT

---

I'm getting the error also on your fork, @zenhack. Trying to debug it, but I'm not very python good.

[zenhack]

Comment by zenhack
Tuesday Dec 13, 2016 at 01:10 GMT

---

@joshmanders, @backbohne, Can you explain how you're setting it up? What OS/distro/versions are you using? Are you installing everything via virtualenv or are some things system packages?

Can you run pip list and paste the output? would be good to know exactly what versions of everything you're running.

(Hard to debug an issue I can' t reproduce...)

[zenhack]

Comment by joshmanders
Tuesday Dec 13, 2016 at 01:27 GMT

---

@zenhack I actually figured out the issue and fixed it in our dokku fork so the letsencrypt plugin worked again. dokku@94baad5

[zenhack]

Comment by zenhack
Tuesday Dec 13, 2016 at 01:40 GMT

---

I'll tweak the bounds in setup.py; I'd just applied @kuba's fix, but like I said I ought to raise the lower bound, and I don't see any reason not to allow 0.9.x if folks report it working.

Passing the directory param by name instead of position shouldn't have any impact; it's already positionally correct:

https://github.com/certbot/certbot/blob/v0.9.3/acme/acme/client.py#L50

Curious as to why you did that?

[zenhack]

Comment by joshmanders
Tuesday Dec 13, 2016 at 02:51 GMT

---

I did it because certbot did it that way. Not a python dev do I don't know if it mattered but it seems to work so I'm not questioning it.

[zenhack]

Comment by backbohne
Tuesday Dec 13, 2016 at 09:46 GMT

---

@zenhack I'm using a self build RPM Python lib package. Build simp_le in two steps

1. pip install "acme>=0.4.1,<0.6"
2. pip install git+https://github.com/kuba/simp_le

works fine ("pip list" gets "acme (0.5.0)"). But if I use your repo, creating new certs will raise #73 again.

Anyway, using my own simp_le fork now and it works for me so far.

[zenhack]

Comment by zenhack
Tuesday Dec 13, 2016 at 16:50 GMT

---

@joshmanders, fair enough. FWIW they're equivalent.

@backbohne, the comments in #73 suggest that it was a symptom of mixing system packages and stuff from pip. If you do the setup according to the README, what do you get?

[zenhack]

Comment by zenhack
Thursday Dec 15, 2016 at 16:48 GMT

---

As a heads up, I turned on the issue tracker on my fork (apparently this is off by default for forks); folks can report stuff there now.

[zenhack]

Fixed, cloasing.

[backbohne]

@zenhack: have not tested, but think so. close this issue will be fine for me.

[ykarikos]

I had the same original problem with @kuba's master version. With your fix, it worked! Thanks a lot for the fix!