`getRemoteCertificates()` is ill-defined #378

dontcallmedom opened this Issue Nov 4, 2015 · 7 comments


None yet

4 participants


The spec is silent about the content of the array buffers returned by getRemoteCertificates()

aboba commented Nov 6, 2015

I have a slightly different question, which is why ArrayBuffer is used rather than RTCCertificate.


Well, ArrayBuffer is (probably) the DER-encoded end-entity certificate. That's pretty useful if you have a DER decoder I guess. RTCCertificate doesn't give you any information other than the expiration date.

getRemoteCertificates() can't return RTCCertificate because RTCCertificate instances can be used for creating a new RTCPeerConnection. That isn't possible for a peer certificate, since an RTCCertificate must include a private key.

aboba commented Nov 8, 2015

It's getRemoteCertificates(), which would seem to imply that more than one certificate can be returned. There are scenarios in which it is possible for a certificate chain to be returned (e.g. a browser talking to a contact center gateway). However, how many WebRTC implementations currently validate a certificate chain used within DTLS?

The most typically suggested use of this method is to retrieve one or more certificates so as to be able to display information to the user. However, since it is up to the application what to do with the certificate(s), any information displayed to the user is potentially untrustworthy

@aboba aboba added a commit that referenced this issue Dec 10, 2015
@aboba aboba Clarification for getRemoteCertificates()
A potential clarification for Issue 378: 
aboba commented Dec 10, 2015

I have submitted a PR that states that getRemoteCertificates() returns a DER-encoded certificate chain. However, it is not clear that there is WG consensus for this interpretation (or for an alternative one, for that matter).

@aboba aboba self-assigned this Dec 10, 2015

Now defined (binary BER encoded).

@alvestrand alvestrand closed this Dec 17, 2015
@aboba aboba added a commit that referenced this issue Jan 8, 2016
@aboba aboba getRemoteCertificates() behavior in "new" and "connecting" states
Issue #378 (not quite closed).
@aboba aboba reopened this Jan 8, 2016
aboba commented Jan 8, 2016

There still may be some ill-defined behavior when getRemoteCertificates() is called before the remote peer has selected a certificate. For example, getRemoteCertificates() could return null until RTCDtlsTransportState transitions to "connected".


Better to open another issue for this new problem.

@aboba aboba closed this Jan 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment