FF138 Relnote: Certificate returns fingerprints

[hamishwillee]

FF138 adds support for the RTCCertificate.getFingerprints() method in https://bugzilla.mozilla.org/show_bug.cgi?id=1525241

This is draft, because I'd quite like a sanity check from the developers - asked in https://bugzilla.mozilla.org/show_bug.cgi?id=1525241

Related docs can be tracked in #38882

[github-actions]

Preview URLs

• /en-US/docs/Mozilla/Firefox/Releases/138
• /en-US/docs/Web/API/RTCCertificate/getFingerprints

Flaws (1)

Note! 1 document with no flaws that don't need to be listed. 🎉

URL: /en-US/docs/Mozilla/Firefox/Releases/138
Title: Firefox 138 for developers
Flaw count: 1

• macros:
  • Macro produces link /en-US/docs/Web/HTML/Element/details which is a redirect

External URLs (1)

URL: /en-US/docs/Mozilla/Firefox/Releases/138
Title: Firefox 138 for developers

• https://bugzil.la/1525241 (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2025-04-11 11:20:26)

[hamishwillee]

This was definitely wrong, because there is no RTCPeerConnection.certificate property.

You can either the RTCCertificate from the RTCPeerConnection.getConfiguration() (which gets your current configuration, as set up in the peer connection constructor) or from a certificate you generate using the static method and pass in.

I think the intent is that the peer connection gets created and creates you some certificates (or you create your own). You then exchange their fingerprints out of band, then start the connection up by creating offer etc. As part of all this DTLS gets setup and the fingerprints sent are used for identity verification.
If that is true, then this is OK - though it could be more informative. Following up in https://bugzilla.mozilla.org/show_bug.cgi?id=1525241

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.