Skip to content

verification of certificate failed #772

Closed
@alanywlee

Description

@alanywlee

In which file did you encounter the issue?

2017-07-27 08:30:19,794 [DEBUG] [r-ELG-49-2] 
verification of certificate failed
java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
 at sun.security.validator.PKIXValidator.<init>(Unknown Source)
 at sun.security.validator.Validator.getInstance(Unknown Source)
 at sun.security.ssl.X509TrustManagerImpl.getValidator(Unknown Source)
 at sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(Unknown Source)
 at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source)
 at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
 at io.netty.handler.ssl.ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify(ReferenceCountedOpenSslClientContext.java:223)
 at io.netty.handler.ssl.ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(ReferenceCountedOpenSslContext.java:606)
 at org.apache.tomcat.jni.SSL.readFromSSL(Native Method)
 at io.netty.handler.ssl.ReferenceCountedOpenSslEngine.readPlaintextData(ReferenceCountedOpenSslEngine.java:470)
 at io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:927)
 at io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1033)
 at io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:200)
 at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1117)
 at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1039)
 at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
 at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
 at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
 at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349)
 at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:341)
 at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
 at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
 at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349)
 at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
 at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:129)
 at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:642)
 at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:565)
 at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:479)
 at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:441)
 at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
 at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
 at java.lang.Thread.run(Unknown Source)
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
 at java.security.cert.PKIXParameters.setTrustAnchors(Unknown Source)
 at java.security.cert.PKIXParameters.<init>(Unknown Source)
 at java.security.cert.PKIXBuilderParameters.<init>(Unknown Source)
 ... 32 more

and

java.util.concurrent.ExecutionException: io.grpc.StatusRuntimeException: UNAVAILABLE: Channel closed while performing protocol negotiation

Did you change the file? If so, how?

No

Describe the issue

I encountered this problem twice, runtime exception just like the following.
The first time is still working with Cloud Speech API Beta, system running about three weeks and about ten thousands requests.
The second time is working with Cloud Speech API GA (checkout at Apr.24,2017), running only less than one hours and about 100 requests. Even exactly the same system was almost non-stop working well at least handling more than 6 thousands requests since Apr. 24 to Jul. 16.

Both of the system verification of certificate failure list above can only be recovered by application restart.
I doubt this issue might not need many requests to make it happen.
And is there any more elegant way to recover other than kill application and restart it.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions