Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why is this verification failing? #12

Closed
alubbe opened this issue May 21, 2016 · 19 comments
Closed

Why is this verification failing? #12

alubbe opened this issue May 21, 2016 · 19 comments

Comments

@alubbe
Copy link

alubbe commented May 21, 2016

Thanks for putting this module together!
I cannot figure out why validation is failing for my host www.muuuf.de. Specifically, this is failing

const https = require("https")
const ocsp = require("ocsp")
const agent = new ocsp.Agent()

https.request({
  host: "www.muuuf.de",
  agent: agent
}, function(res) {
});

even though this

openssl s_client -connect www.muuuf.de:443 -servername www.muuuf.de -status

produces output that looks valid and verified to me:

OCSP response: 
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    Produced At: May 19 16:59:00 2016 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
      Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
      Serial Number: 03677DA61C6153D2591BC59B1B6DE59F527B
    Cert Status: good
    This Update: May 19 16:00:00 2016 GMT
    Next Update: May 26 16:00:00 2016 GMT
@alubbe
Copy link
Author

alubbe commented May 24, 2016

Is this related to #1? How can I find out whether my setup is incorrect or whether this library has not implemented the letsencrypt chain?

@alubbe
Copy link
Author

alubbe commented Jun 2, 2016

I feel bad about bumping this issue again as I am sure you are working on important things. It would be really helpful if you could give me a quick pointer if it's me who is doing something wrong or if it's a missing feature/implementation of this library (and if so, how I might put together a PR fixing it).

With letsencrypt getting more and more traction, this might also help other developers.

@alubbe
Copy link
Author

alubbe commented Jul 7, 2016

Hey @indutny I hope you don't mind me asking - but is this project still maintained?

@indutny
Copy link
Owner

indutny commented Jul 8, 2016

@alubbe I try to, but sometimes I don't have enough time. If you know anyone who will be interested in this, please let me know!

@alubbe
Copy link
Author

alubbe commented Jul 10, 2016

@indutny Like I mentioned above, it seems to fail ocsp validation for every letsencrypt certificate, which, as you know, has several million certificates deployed. So I think there'll be interest in fixing it ;)
Do you have a hunch of what might be going on?

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

I believe that it comes down to this https://community.letsencrypt.org/t/unable-to-verify-ocsp-response/7264/6 . Perhaps non-issuer cert is used to verify the OCSP response.

Going to check this.

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

On other hand CN = Let's Encrypt Authority X3 is in OCSP response...

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

$ ./out/Debug/openssl-cli ocsp -issuer /tmp/issuer.pem -cert /tmp/server.pem -url http://ocsp.int-x3.letsencrypt.org/ -header Host ocsp.int-x1.letsencrypt.org -no_nonce -VAfile /tmp/issuer.pem -text
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
          Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
          Serial Number: 03D4C479F0C3C2B66CAF11DA87C1743CB343
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    Produced At: Jul  8 00:33:00 2016 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
      Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
      Serial Number: 03D4C479F0C3C2B66CAF11DA87C1743CB343
    Cert Status: good
    This Update: Jul  8 00:00:00 2016 GMT
    Next Update: Jul 15 00:00:00 2016 GMT

    Signature Algorithm: sha256WithRSAEncryption
         31:02:ea:5a:e2:03:37:6f:d6:c7:d9:fe:4e:61:ab:8f:81:69:
         65:2e:c5:d6:b9:2b:b5:1f:20:92:87:e6:c0:e1:18:a4:5b:3b:
         48:8d:e1:89:a9:7d:19:b9:30:da:c0:3c:9c:a3:90:e5:85:87:
         ea:d8:2a:46:55:b7:1f:07:2a:a6:e1:b1:a7:b3:e7:bf:9b:2e:
         f8:6b:47:20:5e:6d:ce:6d:8b:66:cd:81:1c:70:e8:35:cc:d4:
         7b:04:96:7c:0a:34:e5:17:e2:c6:88:8e:88:3e:8b:14:4e:2c:
         60:10:c6:e3:08:68:31:c8:e0:9b:e6:44:c7:4f:09:92:8a:17:
         c4:76:af:92:30:b1:17:0d:9e:cc:c2:e3:26:f7:f0:89:62:6e:
         71:34:9f:6b:4c:5d:05:6e:b3:cb:b7:30:b0:b6:46:61:90:7d:
         69:89:73:17:58:2c:9b:1c:ac:56:da:cb:7d:2b:1c:54:54:c4:
         00:1b:23:8d:b5:ad:b0:9c:26:3c:1c:a9:59:ba:e0:fe:cb:73:
         80:4c:ca:a2:b9:05:b2:f6:92:6c:da:43:4c:df:b5:85:be:e7:
         84:b0:b5:0a:23:13:0c:35:3c:9c:de:e6:d8:e6:17:08:b1:85:
         7d:20:af:65:45:fe:ab:52:64:cc:c6:eb:da:c0:8a:82:93:f2:
         04:1b:99:8a
Response verify OK
/tmp/server.pem: good
    This Update: Jul  8 00:00:00 2016 GMT
    Next Update: Jul 15 00:00:00 2016 GMT

OpenSSL appears to be completely fine about it.

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

I suppose there may be a problem with DER encoding somewhere.

@alubbe
Copy link
Author

alubbe commented Jul 10, 2016

Yes, openssl being fine with it was the reason I initially opened this issue. Wouldn't that mean that there is a problem decoding the DER in this module rather than the encondig of it?

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

I believe encoding, will let you know about my findings soon.

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

(FWIW, I can fix it manually, but try to understand why encoding produces different result)

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

Alright, I believe there is a problem with DER encoding in OpenSSL:

This is a description of OCSP ResponseData that is being verified:

ResponseData ::= SEQUENCE {
      version              [0] EXPLICIT Version DEFAULT v1,
      responderID              ResponderID,
      producedAt               GeneralizedTime,
      responses                SEQUENCE OF SingleResponse,
      responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

Where Version is:

Version ::= INTEGER { v1(0) }

This is how asn1.js encodes it (please ignore difference in hashes and serial number):

    0:d=0  hl=3 l= 214 cons: SEQUENCE
    3:d=1  hl=2 l=  76 cons: cont [ 1 ]
    5:d=2  hl=2 l=  74 cons: SEQUENCE
    7:d=3  hl=2 l=  11 cons: SET
    9:d=4  hl=2 l=   9 cons: SEQUENCE
   11:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   16:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :US
   20:d=3  hl=2 l=  22 cons: SET
   22:d=4  hl=2 l=  20 cons: SEQUENCE
   24:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   29:d=5  hl=2 l=  13 prim: PRINTABLESTRING   :Let's Encrypt
   44:d=3  hl=2 l=  35 cons: SET
   46:d=4  hl=2 l=  33 cons: SEQUENCE
   48:d=5  hl=2 l=   3 prim: OBJECT            :commonName
   53:d=5  hl=2 l=  26 prim: PRINTABLESTRING   :Let's Encrypt Authority X3
   81:d=1  hl=2 l=  15 prim: GENERALIZEDTIME   :20160709162100Z
   98:d=1  hl=2 l= 117 cons: SEQUENCE
  100:d=2  hl=2 l= 115 cons: SEQUENCE
  102:d=3  hl=2 l=  75 cons: SEQUENCE
  104:d=4  hl=2 l=   9 cons: SEQUENCE
  106:d=5  hl=2 l=   5 prim: OBJECT            :sha1
  113:d=5  hl=2 l=   0 prim: NULL
  115:d=4  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:7EE66AE7729AB3FCF8A220646C16A12D6071085D
  137:d=4  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
  159:d=4  hl=2 l=  18 prim: INTEGER           :039525A6760821C9988535D31C39E14F877D
  179:d=3  hl=2 l=   0 prim: cont [ 0 ]
  181:d=3  hl=2 l=  15 prim: GENERALIZEDTIME   :20160709160000Z
  198:d=3  hl=2 l=  17 cons: cont [ 0 ]
  200:d=4  hl=2 l=  15 prim: GENERALIZEDTIME   :20160716160000Z

This is how OpenSSL does this:

    0:d=0  hl=3 l= 219 cons: SEQUENCE
    3:d=1  hl=2 l=   3 cons: cont [ 0 ]
    5:d=2  hl=2 l=   1 prim: INTEGER           :00
    8:d=1  hl=2 l=  76 cons: cont [ 1 ]
   10:d=2  hl=2 l=  74 cons: SEQUENCE
   12:d=3  hl=2 l=  11 cons: SET
   14:d=4  hl=2 l=   9 cons: SEQUENCE
   16:d=5  hl=2 l=   3 prim: OBJECT            :countryName
   21:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :US
   25:d=3  hl=2 l=  22 cons: SET
   27:d=4  hl=2 l=  20 cons: SEQUENCE
   29:d=5  hl=2 l=   3 prim: OBJECT            :organizationName
   34:d=5  hl=2 l=  13 prim: PRINTABLESTRING   :Let's Encrypt
   49:d=3  hl=2 l=  35 cons: SET
   51:d=4  hl=2 l=  33 cons: SEQUENCE
   53:d=5  hl=2 l=   3 prim: OBJECT            :commonName
   58:d=5  hl=2 l=  26 prim: PRINTABLESTRING   :Let's Encrypt Authority X3
   86:d=1  hl=2 l=  15 prim: GENERALIZEDTIME   :20160708003300Z
  103:d=1  hl=2 l= 117 cons: SEQUENCE
  105:d=2  hl=2 l= 115 cons: SEQUENCE
  107:d=3  hl=2 l=  75 cons: SEQUENCE
  109:d=4  hl=2 l=   9 cons: SEQUENCE
  111:d=5  hl=2 l=   5 prim: OBJECT            :sha1
  118:d=5  hl=2 l=   0 prim: NULL
  120:d=4  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:7EE66AE7729AB3FCF8A220646C16A12D6071085D
  142:d=4  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
  164:d=4  hl=2 l=  18 prim: INTEGER           :03D4C479F0C3C2B66CAF11DA87C1743CB343
  184:d=3  hl=2 l=   0 prim: cont [ 0 ]
  186:d=3  hl=2 l=  15 prim: GENERALIZEDTIME   :20160708000000Z
  203:d=3  hl=2 l=  17 cons: cont [ 0 ]
  205:d=4  hl=2 l=  15 prim: GENERALIZEDTIME   :20160715000000Z

To conclude OpenSSL encodes version=v1 even though it shouldn't put it at all, because it is equal to he default value. (See http://luca.ntop.org/Teaching/Appunti/asn1.html 5.12):

DER encoding. Constructed. Contents octets are the same as the BER encoding, except that if the value of a component with the DEFAULT qualifier is the default value, the encoding of that component is not included in the contents octets.

I'm going to investigate it a bit more, but this is how things look like at the moment.

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

Yeah, it is definitely prohibited by X.690:

11.5 Set and sequence components with default value
The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to
its default value. 

See: https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

See: openssl/openssl#1297

@indutny
Copy link
Owner

indutny commented Jul 10, 2016

Turns out this is a golang bug: https://go-review.googlesource.com/#/c/24841/

@indutny
Copy link
Owner

indutny commented Jul 11, 2016

@alubbe I have managed to fix it anyway, please give it a try. Hope it works for you now!

@alubbe
Copy link
Author

alubbe commented Jul 11, 2016

Can confirm that it works now.
Thanks so much, it turned out to be pretty interesting ;)

@indutny
Copy link
Owner

indutny commented Jul 11, 2016

Indeed it did! Thank you for reporting this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants