Closed lyubomir closed 9 years ago
The media session is now torn down by default if the fingerprint does not match the hashed certificate in jitsi/libjitsi commit d364e8e13e49f8f4e80104fe92c02cff39b6c1a6. This issue may be closed after the modifications bubble up to jitsi/jitsi-videobridge and/or its nightly build.
Thanks lyubomir!
@lyubomir I used the latest jvb to build, and MeetRTC_iOS repo to connect to jvb, but now it still showed this error, how to fix it?
JVB 2016-04-19 17:02:55.498 SEVERE: [131] org.jitsi.impl.neomedia.transform.dtls.TlsServerImpl.error() Failed to verify and/or validate client certificate!
java.io.IOException: No fingerprints declared over the signaling path!
at org.jitsi.impl.neomedia.transform.dtls.DtlsControlImpl.verifyAndValidateCertificate(DtlsControlImpl.java:858)
at org.jitsi.impl.neomedia.transform.dtls.DtlsControlImpl.verifyAndValidateCertificate(DtlsControlImpl.java:947)
at org.jitsi.impl.neomedia.transform.dtls.TlsServerImpl.notifyClientCertificate(TlsServerImpl.java:417)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.notifyClientCertificate(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.processClientCertificate(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.serverHandshake(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.accept(Unknown Source)
at org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.runInConnectThread(DtlsPacketTransformer.java:1048)
at org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.access$100(DtlsPacketTransformer.java:40)
at org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer$2.run(DtlsPacketTransformer.java:1277)
JVB 2016-04-19 17:02:55.500 SEVERE: [131] org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.error() Failed to accept a connection from a DTLS client!
java.io.IOException: No fingerprints declared over the signaling path!
at org.jitsi.impl.neomedia.transform.dtls.DtlsControlImpl.verifyAndValidateCertificate(DtlsControlImpl.java:858)
at org.jitsi.impl.neomedia.transform.dtls.DtlsControlImpl.verifyAndValidateCertificate(DtlsControlImpl.java:947)
at org.jitsi.impl.neomedia.transform.dtls.TlsServerImpl.notifyClientCertificate(TlsServerImpl.java:417)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.notifyClientCertificate(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.processClientCertificate(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.serverHandshake(Unknown Source)
at org.bouncycastle.crypto.tls.DTLSServerProtocol.accept(Unknown Source)
at org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.runInConnectThread(DtlsPacketTransformer.java:1048)
at org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer.access$100(DtlsPacketTransformer.java:40)
at org.jitsi.impl.neomedia.transform.dtls.DtlsPacketTransformer$2.run(Dt
@zoomchan-cxj Ihad this issue also , did you solve it already ?
Gavin Llewellyn wrote:
I noticed something in a JVB log file that has me concerned:
2015-06-28 16:43:34.267 WARNING: [12159] org.jitsi.impl.neomedia.transform.dtls.DtlsControlImpl.warn() Failed to verify and/or validate a certificate offered over the media path against fingerprints declared over the signaling path! No fingerprints declared over the signaling path!
The root cause of the lack of fingerprints may be that we’re not driving the REST interface correctly; I haven’t looked into that yet. What worries me is that the media is working despite this warning message. JVB has apparently been unable to verify the fingerprint, but continues regardless. Surely this is not a good idea.
Looking at the code in DtlsControlImpl, it appears a similar result would arise if the fingerprint was signalled but did not match: verifyAndValidateCertificate() prints a warning and returns false, but the return value is never used. According to a comment in that file, not tearing down the connection appears to be deliberate. Am I missing something?