starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

Certificate Revocation List for users #2198

New issue

Open

opened 2026-02-20 22:01:47 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-20 22:01:47 -05:00

Owner

Originally created by @EP-u-NW on GitHub (May 3, 2021).

It is currently not possible to add CRLs (certificate revocation lists) to a server. The problem here is that Qt doesn't allow adding a crl to a QSslConfiguration or QSslSocket.

CRLs seem to be a bit outdatet in favour of the Online Certificate Status Protocol (OCSP). Boldly spoken, in OCSP a certificate contains a link to a place where a CA publishes a CRL so that the peer receiving the certificate can follow this link and check the newest CRL from there. OCSP is discussed in #1231 but from an other perspective: In our case, the mumble server is the certificate receiving peer (in form of user certificates), not the mumble client (as in #1231 with the servers certificate).

For user certificates a CRL might actually be better suited then the OCSP and could act as additional blacklist.

The best solution for this would be to contact Qt and ask them to implement CRLs, but it seems that is out of Qt's scope. In the meantime, we could try validating the client certificates manually after the actual ssl handshake, e.g. if an authenticate message arrives.

The general scheme could be something like:

create a X509_STORE_CTX
configure the context

	void X509_STORE_CTX_set_cert(X509_STORE_CTX *ctx,X509 *x);
	void X509_STORE_CTX_set_chain(X509_STORE_CTX *ctx,STACK_OF(X509) *sk);
	void X509_STORE_CTX_set0_crls(X509_STORE_CTX *ctx, STACK_OF(X509_CRL) *sk);

create X509_VERIFY_PARAM
configure the params

	int X509_VERIFY_PARAM_set_flags(X509_VERIFY_PARAM *param, unsigned long flags) with X509_V_FLAG_CRL_CHECK

wire up params to context

	void X509_STORE_CTX_set0_param(X509_STORE_CTX *ctx, X509_VERIFY_PARAM *param);

finally, verify the whole thing

	X509_STORE_CTX_verify

Honestly, I don't know the performance implications of doing this manually instead of openssl doing this for us...

Originally created by @EP-u-NW on GitHub (May 3, 2021). It is currently not possible to add CRLs (certificate revocation lists) to a server. The problem here is that Qt doesn't allow adding a crl to a `QSslConfiguration` or `QSslSocket`. CRLs seem to be a bit outdatet in favour of the Online Certificate Status Protocol (OCSP). Boldly spoken, in OCSP a certificate contains a link to a place where a CA publishes a CRL so that the peer receiving the certificate can follow this link and check the newest CRL from there. OCSP is discussed in #1231 but from an other perspective: In our case, the mumble server is the certificate receiving peer (in form of user certificates), not the mumble client (as in #1231 with the servers certificate). For user certificates a CRL might actually be better suited then the OCSP and could act as additional blacklist. The best solution for this would be to contact Qt and ask them to implement CRLs, but it seems [that is out of Qt's scope](https://forum.qt.io/topic/122187/qt-check-ssl-certificate-if-it-was-revoked-crl-file/4). In the meantime, we could try validating the client certificates manually after the actual ssl handshake, e.g. if an authenticate message arrives. The general scheme could be something like: 1. create a X509_STORE_CTX 2. configure the context ``` void X509_STORE_CTX_set_cert(X509_STORE_CTX *ctx,X509 *x); void X509_STORE_CTX_set_chain(X509_STORE_CTX *ctx,STACK_OF(X509) *sk); void X509_STORE_CTX_set0_crls(X509_STORE_CTX *ctx, STACK_OF(X509_CRL) *sk); ``` 3. create X509_VERIFY_PARAM 4. configure the params ``` int X509_VERIFY_PARAM_set_flags(X509_VERIFY_PARAM *param, unsigned long flags) with X509_V_FLAG_CRL_CHECK ``` 5. wire up params to context ``` void X509_STORE_CTX_set0_param(X509_STORE_CTX *ctx, X509_VERIFY_PARAM *param); ``` 6. finally, verify the whole thing ``` X509_STORE_CTX_verify ``` Honestly, I don't know the performance implications of doing this manually instead of openssl doing this for us...

deekerman added the

feature-request

server

certificate

labels

2026-02-20 22:01:47 -05:00

deekerman commented

2026-02-20 22:01:48 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (May 3, 2021):

I assume the X509* functions are OpenSSL ones? 👀

@Krzmbrzl commented on GitHub (May 3, 2021): I assume the X509* functions are OpenSSL ones? :eyes:

deekerman commented

2026-02-20 22:01:49 -05:00

Author

Owner

@EP-u-NW commented on GitHub (May 3, 2021):

Oh yes, forgot to mention that 😅 Doing quite much OpenSSL atm...

@EP-u-NW commented on GitHub (May 3, 2021): Oh yes, forgot to mention that 😅 Doing quite much OpenSSL atm...

deekerman commented

2026-02-20 22:01:49 -05:00

Author

Owner

@EP-u-NW commented on GitHub (Jun 13, 2021):

So we want to start working on this, but I read some issues/discussion posts about a complete server rewrite. Can you give a short introduction about that? Might it be better to wait with implementing crl until the rewrite is done and implement crl support there?

@EP-u-NW commented on GitHub (Jun 13, 2021): So we want to start working on this, but I read some issues/discussion posts about a complete server rewrite. Can you give a short introduction about that? Might it be better to wait with implementing crl until the rewrite is done and implement crl support there?

deekerman commented

2026-02-20 22:01:49 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jun 14, 2021):

There are no plans on a server rewrite. The topic was brought up once but after some discussion we concluded that a step-wise refactoring is the way to go.

@Krzmbrzl commented on GitHub (Jun 14, 2021): There are no plans on a server rewrite. The topic was brought up once but after some discussion we concluded that a step-wise refactoring is the way to go.

deekerman commented

2026-02-20 22:01:49 -05:00

Author

Owner

@Neustradamus commented on GitHub (May 7, 2024):

Very important!

@Neustradamus commented on GitHub (May 7, 2024): Very important!