Openssl problem while using trust certs

Help Kubernetes
#1

env: k8s
version: 1.3.1

We configured linkerd with a couple of trust certs on port 443, this config is not allowing endpoints with certs which are not specified. Example, google.com. Is there a way to add few trust certs and also allow for endpoints which are ca certified but not specified in the config?

  - prefix: "/$/io.buoyant.rinet/443/{service}"
      tls:
        trustCerts:
        - /io.buoyant/linkerd/EP-1/cacertificate1.pem
        - /io.buoyant/linkerd/EP-2/cacertificate2.pem
        commonName: "{service}"

testing

http_proxy=$(kubectl get svc l5d -o jsonpath="{.status.loadBalancer.ingress[0].*}"):4140 curl -v http://www.google.com:443

General OpenSslEngine problem at remote address: www.google.com/74.xxx.xx.103:443

log

WARN 1226 14:16:07.498 UTC finagle/netty4-32: An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:459)
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1342)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:934)
        at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
        at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:645)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:580)
        at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:497)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:459)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at com.twitter.finagle.util.BlockingTimeTrackingThreadFactory$$anon$1.run(BlockingTimeTrackingThreadFactory.scala:23)
        at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem
#2

You’ll have to add a path to the root certs in the config. This is usually managed as a part of the operating system or base container image (though it’s common practice to mount certs into a container).

For example, on a macOS host, I have:

$ ls -l /etc/ssl/cert.pem
-rw-r--r--  1 root  wheel   222K Jul 15 21:40 /etc/ssl/cert.pem

This file contains the many root certificates trusted by the operating system.

1 Like