Unexpected character encountered while parsing value

[timmy8ken]

Hello ACMESharp-ers

I have been successfully using the ACMESharp cmdlets to manage our certificates, but I have just recently hit upon a hurdle renewing one of my existing SAN certificates.

I have successfully managed to create a new certificate, using the original identifier (api being the loadbalancer IP and svr-api-01 and svr-api-02 being the server host names):

I then tried to submit the certificate and got an Unexpected error:

If I try and update the certificate I get the following error:

I have checked the folders in C:\ProgramData\ACMESharp\sysVault\ for the right files and they all appear there and correct and I have compared them to the other certificate files and they look very similar. I have also tried remove the relevant files and creating them again but I always end up with the same problem.

I am currently using 0.8.1, which I believe is the latest version, and it is running in PowerShell 5

Hopefully someone has seen this before, however I could find any reference to it on any of the issues page. If you need any more info then please let me know.

Cheers,

Tim

[ebekker]

Tim, can you try specifying the SAN refs list using the following notation (explicit array): @(ref1,ref2,ref3)

[timmy8ken]

Hi Eugene,

I get the same problem when using the explicit array:

Tim

[bseddon]

The exception reported is a JsonReaderException from the NewtonSoft JSON package. What does the JSON look like in files generated for the respective certificate JSON files? You will find them in 30-CSRDT, 40-KEYGN and 50-CSRGN. Does the vault file itself (another JSON file) parse OK?

[timmy8ken]

Hi Bill,

I have checked my JSON files and 30 and 40 look good. 50 is just an open and close braces, these are the file contents:

30-CSRDT: { "$type": "ACMESharp.PKI.CsrDetails, ACMESharp", "CommonName": "api.XX", "AlternativeNames": [ "svr-XX", "svr-XX" ], "Country": null, "StateOrProvince": null, "Locality": null, "Organization": null, "OrganizationUnit": null, "Description": null, "Surname": null, "GivenName": null, "Initials": null, "Title": null, "SerialNumber": null, "UniqueIdentifier": null, "Email": null }

40-KEYGN: { "Bits": 2048, "E": "010001", "BigNumber": null, "Pem": "-----BEGIN RSA PRIVATE KEY-----\nREMOVED==\n-----END RSA PRIVATE KEY-----\n" }

50-CSRGN {}

The vault file (00-VAULT) parses correctly when run through a JSON validator.

Tim

[JackUkleja]

I am getting this problem a lot, for almost all the the commands. I am following the quick-start guide (which is very good). Things seemed to be working initially until our first validation failed. When I restarted the guide from the beginning it seems everything is now hanging up and either giving me timeouts or this parsing error. I have tried the latest 0.8.1 and also the 0.8.2.295 preview. I've tried staging and prod, and I've also tried on different computers. I've tried deleting the vault. My guess is letsencrypt.org is returning some strange messages that ACMESharp can't handle but it's not really giving me any details. Basically I'm stuck. Any clues what's going on?

[JackUkleja]

Ah, this could be a service interruption (although I'm sure I tried staging servers too): https://letsencrypt.status.io/pages/55957a99e800baa4470002da

[JackUkleja]

It's working again now.

But I wonder whether the error handle in ACMESharp can be improved? This error "Unexpected character encountered while parsing value" could be coming from the code expecting json but the LE website returning an error presumably in HTML which is why it gets a '<' character - the start of an error page coming back from LE?

[cpu]

This error "Unexpected character encountered while parsing value" could be coming from the code expecting json but the LE website returning an error presumably in HTML which is why it gets a '<' character - the start of an error page coming back from LE?

That's correct. During the incident instead of a JSON response from Boulder/LE the client was receiving an HTML error page from the CDN edge.

[ebekker]

A separate ticket has been created to address improved error-handling and messaging.

The root cause of these issues appears to be LE servers being inaccessible. For such situations we can try to automatically perform retries, or detect service unavailability.