TLS Doesn't Work with SHA512 Certs

Issue Type:

• Bug report
• Feature request

What happened: Requests error out when sending via linkerd secured with tls when using certificates using SHA512. We’ve followed the guide, which works with the provided sample certs, but breaks when we substitute our own certs generated with SHA512 instead of SHA256.

What you expected to happen: SHA512 certs should work the same as SHA256.

How to reproduce it (as minimally and precisely as possible): Use the openssl commands provided here, and the openssl.cfg file provided here, substituting the algorithm with SHA512 (i.e. default_md = sha512). Make a request and observe the errors:

E 0309 15:23:41.199 UTC THREAD120 TraceId:0ea20f703404c448: service failure: Failure(null at remote address: /10.0.24.7:4141. Remote Info: Not Available at remote address: /10.0.24.7:4141. Remote Info: Not Available, flags=0x09) with RemoteInfo -> Upstream Address: Not Available, Upstream id: Not Available, Downstream Address: /10.0.24.7:4141, Downstream label: %/io.l5d.k8s.daemonset/linkerd/incoming/l5d/#/io.l5d.k8s/default/http/consumer, Trace Id: 0ea20f703404c448.0ea20f703404c448<:0ea20f703404c448
I 0309 15:28:50.204 UTC THREAD68 TraceId:9023d4a952049423: FailureAccrualFactory marking connection to "%/io.l5d.k8s.daemonset/linkerd/incoming/l5d/#/io.l5d.k8s/default/http/consumer" as dead. Remote Address: Inet(/10.0.24.7:4141,Map(nodeName -> ip-10-0-24-7.ec2.internal))

Anything else we need to know?: We posted this on the forums while debugging the issue.

Environment:

• linkerd/namerd version, config files:
  • linkerd 1.3.6
  • linkerd config:

admin:
  ip: 0.0.0.0
  port: 9990

namers:
- kind: io.l5d.k8s
  host: localhost
  port: 8001

telemetry:
- kind: io.l5d.prometheus
- kind: io.l5d.recentRequests
  sampleRate: 0.25

usage:
  orgId: linkerd-examples-daemonset

routers:
- protocol: http
  label: outgoing
  dtab: |
    /srv        => /#/io.l5d.k8s/default/http;
    /host       => /srv;
    /svc        => /host;
  interpreter:
    kind: default
    transformers:
    - kind: io.l5d.k8s.daemonset
      namespace: linkerd
      port: incoming
      service: l5d
      hostNetwork: true
  servers:
  - port: 4140
    ip: 0.0.0.0
  service:
    responseClassifier:
      kind: io.l5d.http.retryableRead5XX
  client:
    tls:
      commonName: linkerd
      trustCerts:
      - /io.buoyant/linkerd/certs/cacertificate.pem

- protocol: http
  label: incoming
  dtab: |
    /srv        => /#/io.l5d.k8s/default/http;
    /host       => /srv;
    /svc        => /host;
  interpreter:
    kind: default
    transformers:
    - kind: io.l5d.k8s.localnode
      hostNetwork: true
  servers:
  - port: 4141
    ip: 0.0.0.0
    tls:
      certPath: /io.buoyant/linkerd/certs/certificate.pem
      keyPath: /io.buoyant/linkerd/certs/key.pk8

• Platform, version, and config files (Kubernetes, DC/OS, etc):
  • Kubernetes 1.9.3
  • CoreOS 1632.3.0
• Cloud provider or hardware configuration: AWS

[a-kinder]

coworker of @Capitrium here, issue is resolved.

To reiterate publicly from my e-mail yesterday with Brian:

I realized that the common name was being overridden by the subject alternative names, so although we had “linkerd” as the CN in both the linkerd config file as well as the certificates, it was being overridden by our DNS name entries. Both our cfssl certificates and vault certificates worked once I changed the commonName to “l5d” in our linkerd config. I think the openssl ones worked because they didn’t have a subject alternative name therefore it wasn’t overriding the “linkerd” common name, and the cfssl certs worked in linkerd-tcp because it doesn’t specify common name in it’s configuration at all.

[briansmith]

@Capitrium That’s right, I got them! Thanks! I don’t see anything out of the ordinary with those certificates. I actually just filed #1876 to make our example certificates look more like what you sent!

I’m now going to attempt to create my own root CA and end-entity certificate with CFSSL and see if I can reproduce the issue with CFSSL-generated certificates in linkerd.