Certificates with OCSP Must-Staple fail when connecting from Firefox

[hashworks]

Describe the bug
I'm using a WebRTC publisher on TLS port 3334 using Let's Encrypt certificates created with --must-staple. When I connect using Chromium, everything works as expected. When I connect using Firefox the WebSocket-Connection times out and the Server logs the following:

[SPRtcSig-T3334:275556] OpenSSL | tls.cpp:193  | An error occurred while accept SSL connection: [OpenSSL] error:0A000412:SSL routines::sslv3 alert bad certificate (167773202)

The error occurs here.

When I re-create the certificates without --must-staple everything works as expected.

To Reproduce
Steps to reproduce the behavior:

1. Create certificates with OCSP Must-Staple
2. Set Server.xml like this
3. Publish using any configured provider (RTMP)
4. Open wss://stream.example.net:3334/live/stream with an OvenPlayer in Chromium, see that it works
5. Open wss://stream.example.net:3334/live/stream with an OvenPlayer in Firefox, note the timeout and the SSL error in the OvenMediaEngine Log

Expected behavior
The server can handle OCSP Must-Staple.

Logs
There are no other relevant log messages than the OpenSSL error, even with debug logging.

Server:

• OS: Arch Linux
• OvenMediaEngine Version: v0.14.14
• Branch: git tag

Player:

• Device: OvenPlayer Demo
• OS: Arch Linux
• Browser: Chromium (:heavy_check_mark:) / Firefox (:x:)
• Version: Firefox 106.0.2

Additional context
The certificate looks like this (note the OCSP info).

[getroot]

Thank you for reporting good info. If this is a bug in OME, why does it work well with Chrome? Any reason you're sure it's a bug in OME? If you share the reason, it will be easier to solve the problem.

[hashworks]

If this is a bug in OME, why does it work well with Chrome?

I have a feeling Chrome isn't handling things correctly here - the certificate demands OCSP stapling, the server doesn't handle it and Chrome then ignores the issue. With Firefox the connection fails as it should.

Any reason you're sure it's a bug in OME?

When I move the TLS termination of the websocket connection to nginx, the stream works just fine in Firefox:

upstream ome {
        server 127.0.0.1:3333;
        keepalive 256;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {
    [...]

  ssl_certificate           /etc/letsencrypt/live/stream.example.netfullchain.pem;
  ssl_certificate_key       /etc/letsencrypt/live/stream.example.net/privkey.pem;
  ssl_stapling_file         /etc/letsencrypt/ocspresponse/stream.example.net.der;    

    location /live/ {
      proxy_pass http://ome;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
      proxy_set_header Host $host;
      proxy_connect_timeout 10s;
      proxy_send_timeout 10s;
      proxy_read_timeout 1d;
    }
  }

Note the ssl_stapling_file parameter here - I actually need to do this, because nginx lazy-loads OCSP responses, causing the first connections to fail.

As you see the server actually needs to handle the OCSP stuff, I don't know if the OpenSSL library does this by default or needs special configuration.

[getroot]

Thanks for sharing information. I have to do some research on this. Or it would be great if you could PR for this.

[dimiden]

I have successfully tested the playback with a certificate with the --must-staple option in FireFox.
Now you can use OCSP stapling on OME! 48900ca