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

Caddy can't proxy to sites with big ObjectIdentifier #2518

Closed
lukenowak opened this issue Mar 12, 2019 · 5 comments

Comments

@lukenowak
Copy link
Contributor

commented Mar 12, 2019

1. Which version of Caddy are you using (caddy -version)?

Caddy v0.11.5

2. What are you trying to do?

Proxy to a HTTPS backend served with specific certificate.

3. What is your Caddyfile?

http://erp5.example.com:8080 {
  bind 10.0.0.246
  # Compress the output
  gzip
  log / _erp5_access_log "{remote} {>REMOTE_USER} [{when}] \"{method} {uri} {proto}\" {status} {s
ize} \"{>Referer}\" \"{>User-Agent}\" {latency_ms}"
  errors _erp5_error_log
  # Zope configuration
  # Default proxy configuration
  proxy / https://[fd46::60fb]:2152 {
    try_duration 5s
    try_interval 250ms
    # As backend is trusting REMOTE_USER header unset it always
    header_upstream -REMOTE_USER
    transparent
    timeout 600s
    insecure_skip_verify
  }
  rewrite {
    regexp (.*)
    to /VirtualHostBase/{scheme}%2F%2F{hostonly}:443%2F%2FVirtualHostRoot/{1}
  }
}

4. How did you run Caddy (give the full command and describe the execution environment)?

export CADDYPATH=var/frontend_cluster                                                                          
caddy \                                                                 
        -conf Caddyfile \                                                                                  
        -log stdout -http2=true -grace 5s -disable-http-challenge \                                                                     
        -disable-tls-sni-challenge

5. Please paste any relevant HTTP request(s) here.

curl -v --resolve erp5.example.com:8080:10.0.0.246 http://erp5.example.com:8080/
* Added erp5.example.com:8080:10.0.0.246 to DNS cache
* About to connect() to erp5.caddyrandom.nowak.io port 8080 (#0)
*   Trying 10.0.0.246...
* Connected to erp5.example.com (10.0.0.246) port 8080 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: erp5.example.com:8080
> Accept: */*
>
< HTTP/1.1 502 Bad Gateway
< Content-Type: text/plain; charset=utf-8
< Server: Caddy
< X-Content-Type-Options: nosniff
< Date: Tue, 12 Mar 2019 10:10:45 GMT
< Content-Length: 16
<
502 Bad Gateway

6. What did you expect to see?

I expect Caddy to serve page from the backend.

7. What did you see instead (give full error messages and/or log)?

Instead of served page I have 502 Bad Gateway and such information in the access/error log:

10.0.0.246 - [12/Mar/2019:10:10:45 +0000] "GET / HTTP/1.1" 502 16 "-" "curl/7.29.0" 5057
12/Mar/2019:10:10:45 +0000 [ERROR 502 /VirtualHostBase/http//erp5.example.com:80//VirtualHostRoot/] tls: failed to parse certificate from server: asn1: structure error: base 128 integer too large

8. Why is this a bug, and how do you think this should be fixed?

It's a bug, because backend certificate is correct. It seems a Go bug, related one is closed golang/go#19933, but new one is opened golang/go#30757, as there is no limit regarding ObjectIdentifier.

9. What are you doing to work around the problem in the meantime?

I am just using certificate with smaller ObjectIdentifier, similar to elastic/beats#4093

10. Please link to any related issues, pull requests, and/or discussion.

Interesting issues:

Also, my test certificate and key used on the backend:

-----BEGIN CERTIFICATE-----
MIIDsDCCApigAwIBAgIUZ5wVrp/nIrLFjs0hP7W/CkVjWt4wDQYJKoZIhvcNAQEL
BQAwNDEyMDAGA1UEAwwpQ2F1Y2FzZSBDQVMgYXQgaHR0cDovLzEwLjAuMC4yMjA6
ODg5MC9jYXMwHhcNMTkwMzEyMDc1MjQyWhcNMTkwNjEzMDc1MjQyWjAWMRQwEgYD
VQQDDAtleGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AL0ZORa5vNBgVUAHOdlsnpiPuG+wF78qS9vhj/EqZv2m/pnXdXnl+lSdY723/dl0
DLcSZN5U7wN0WMwm7vSoAX0U+yd3tAN9vz2N9rqbCvxmDdLVbxHPj17bTYBz6SfY
o+l+SzkWc9z0OiAZZK+zCrA1H0ACjRJE2nXkLLGIzuLox9EfqFhu60fwr1hj+hle
7a0/2s4BxeDmGXI7lpcmUZjEyPbk2l6qugWMVkqTl5t5FkeCOEPIvV596UG3mmVy
9F+pWqh5XXe1uDE77RY04WlWcNzp7xJKDQZjA8xkox6FBUAHOJfXIaConfMrYUYD
EOBL3LauSSWGitg+ZnvXYMMCAwEAAaOB1zCB1DAMBgNVHRMBAf8EAjAAMB0GA1Ud
DgQWBBSUsxTF4tJ7G2EeU8T40U/YDuWbgzAfBgNVHSMEGDAWgBQef3rtCb4JIxdj
bIIxbHZ/bFS66TAvBgNVHR8EKDAmMCSgIqAghh5odHRwOi8vMTAuMC4wLjIyMDo4
ODkwL2Nhcy9jcmwwUwYDVR0gBEwwSjBIBhVpg63RrtXU8PqNkb3DtL7vxZWrfQAw
LzAtBggrBgEFBQcCAjAhDB9BdXRvLXNpZ25lZCBjYXVjYXNlIGNlcnRpZmljYXRl
MA0GCSqGSIb3DQEBCwUAA4IBAQC/59Bcp1m/UGfDreA2/Vg1GWn1KJD24uIBoT6i
G1UEDvzUZ/0hkQOnWc7O6J/2+VftwztZtdNjc+ZiELZeMv85yXwkeuTJpxtBqMB9
gM3u1py451Lf2xHs4lKcza9hhyGieMhfXyujxnSNgKulHxoqwo2QLh+vuUcdR1Jm
qAST36eAU3+VnPOSC77/78UiZCaxdYf3E5rsGvdCT6s4vaqljcg2FSF5n/Nsi2M8
VXcyx7ZJBJ/XLT9Ni0eJXkzAYKnmr9d26GV886YFV9KEZOci2SxyM2ZntJEvOGOH
6DkztrYn8EY/fuu/T/iUm8XslNsfbJBE0uXER+tYTE68N4zV
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC9GTkWubzQYFVA
BznZbJ6Yj7hvsBe/Kkvb4Y/xKmb9pv6Z13V55fpUnWO9t/3ZdAy3EmTeVO8DdFjM
Ju70qAF9FPsnd7QDfb89jfa6mwr8Zg3S1W8Rz49e202Ac+kn2KPpfks5FnPc9Dog
GWSvswqwNR9AAo0SRNp15CyxiM7i6MfRH6hYbutH8K9YY/oZXu2tP9rOAcXg5hly
O5aXJlGYxMj25NpeqroFjFZKk5ebeRZHgjhDyL1efelBt5plcvRfqVqoeV13tbgx
O+0WNOFpVnDc6e8SSg0GYwPMZKMehQVABziX1yGgqJ3zK2FGAxDgS9y2rkklhorY
PmZ712DDAgMBAAECggEADkwI5/H1F6Ag8e1Z71lqCEjdffxHX1m4UJCWTHqTPNxS
ZZlHtYawzZL0xpRRqg4/I9xNKg4r4Av85rqO2IqXSji64HoJbzYjrmi8XdF5HCov
I2ClvCgARAC6tFqPJ0cW5YF5+H/9FJiWiHTDCxGzXi02BqXqupXgGoe85VNdqQQl
MRZ3/lUk+tEXuMiDUFrg7tJxrUOTDLtE1AD1ZuQa0ZGWsrN+u2VfGWhiQHiTpdvL
uAsYO9RqM6XQq2WF+RCBGBH7poU5b8aID6x8wckCacALtuRv9AeOkk3oLzkAFwvf
FU/g+WdrPs5MzhPsmlSV1A2RF0OQPDlMPA2kM0aaMQKBgQDtkqV2HqdOYiPjs3gs
AtqfhbR8cEqaLEm8ZIDtqWNwkQdo2Tg7Ww34rGRV+3JIg9rmjdg1Zmz9RWaYzoVC
TgWCtRckAqff2XIzUFrNGz0hFQyv/I43YqsTA3aRMesbXzVEr81pq5vDezlkeLnR
ZHm6YKxgiJRiiM4Bo0KjnMxuKQKBgQDLxAyB2gmSq4SksfrwFyB5Qi8e78Jq4EBR
uZPxHM1HWAGPOCsgVlKXJj3FDo7H6gbHNx3HMg4zGd18GJD5q1HYwoorDHutaIin
vd+1LLu00gRX5XcbojaiSpwikVIKxG2o1vUHBC8kKp/cg3KCLTdJIs/wfJkgOsnE
tPbJzHQdCwKBgHpEq/WDxzV3GuN4nVOBUIUjKgWVQT/hpT1ZOGWYdP4dFgQnL2KU
9TbTenwqAeJCQinAPNMW2ObsjeX8++ZpAzsG+lblKwLxBW5VX7YJ28cn7zSvtX3Z
wRPzB1WorEiVEnQ8SmqlEHBl/d6wp2mV3XRHhs/T2xJvOB7tqEFOVIQpAoGANSBd
XnG5szry73nUAksVVWgzHu7GEtV7D5PCBchLoUFJzsyHOfwntm7rBfjAs1DKCaDO
K8RaPWqN+6/wBJhtU4WNPqIXkOPDVXDE5djO69sh9MTIJDVL505qnPykllgWe0Ho
SrcFj3lpirXe4h/l3TStYHcr+WI6fwXrnjunPncCgYEA5EXptgC11KjNshvW4jJn
wGvOPNvCiqgJLY/86RBoesSEjuA/2n8WM3CPGhOX8ogy8jTBN24u8yFPTG9bpDiC
o/SYmKyuHtGh6pYPsFIpHQzOs0DKciFonMQ3xj0eWG31psZn/GN8GSwl9BzcbT/+
EnwOD7LHgrHAcFF/K08lrSc=
-----END PRIVATE KEY-----
@mholt

This comment has been minimized.

Copy link
Member

commented Mar 12, 2019

Well phooie, that is certainly a fun bug!

@lukenowak Is this related to the instantaneous 502 errors you were reporting before?

In any case, thanks for filling out the issue template. Looks like this would have to be fixed in the Go standard library. How critical are large OIDs to your operation?

@Tomo59

This comment has been minimized.

Copy link

commented Mar 13, 2019

@mholt this is not related at all to 502 errors reported before.

We need an OID to be used for in our certificates and the free OID available without registration are unfortunately not common. The only arc freely available (to our knowledge) is 2.25 (https://oidref.com/2.25) and this one requires to use 128 bits integer after 2.25.

We are trying to see how feasible it is to register an OID but we don't know what to expect.

Anyway, the ideal solution would be that go supports large OID integers but from golang/go#19933 (comment) it's not going to happen soon.

@lukenowak

This comment has been minimized.

Copy link
Contributor Author

commented Mar 13, 2019

@lukenowak Is this related to the instantaneous 502 errors you were reporting before?

Not at all, we found it separately.

@mholt

This comment has been minimized.

Copy link
Member

commented Mar 15, 2019

Awaiting an update from the Go team about it, but haven't heard anything this week. Will see about starting a fix anyway next week, but until we hear from them, it's hard to say whether it'd make it into the standard library.

@mholt

This comment has been minimized.

Copy link
Member

commented Mar 30, 2019

Difficult to fix. Cheaper to get a different OID (as discussed out-of-band). Will close for now. Thank you!

@mholt mholt closed this Mar 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.