openvpn
openvpn copied to clipboard
OpenVPN
support configure multiple certificates on the server side
support configure multiple certificates on the server side, such as ECC and RSA.
openvpn server configure both ECC and RSA certificates, then openvpn clients can choose different certificates according to cipher suite.
server config: ca /opt/local/certs/CA.crt cert /opt/local/certs/RSA_S.crt key /opt/local/certs/RSA_S.key cert /opt/local/certs/ECC_S.crt key /opt/local/certs/ECC_S.key
client1 config: ca /opt/local/certs/CA.crt cert /opt/local/certs/RSA_C.crt key /opt/local/certs/RSA_C.key tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 tls-version-max 1.2
client2 config: ca /opt/local/certs/CA.crt cert /opt/local/certs/ECC_C.crt key /opt/local/certs/ECC_C.key tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 tls-version-max 1.2
The whole documentation is missing. But in the end this PR comes down to calling SSL_CTX_use_certificate multiple times different certificates.
OpenSSL says:
The internal certificate store of OpenSSL can hold several private key/certificate pairs at a time. The certificate used depends on the cipher selected, see also SSL_CTX_set_cipher_list(3).
I still wonder what the use case for this is? Hardcoding tls-cipher to force a specific certificate from the server sounds like a very crazy workaround/hack. I am not sure this even works for TLS 1.3.
I'm also not convinced of the use case even for TLS 1.2 and older. If ECDHE-ECDSA is preferred for key exchange just use an EC cert on the server. For client certificate, some having EC and some RSA require no changes.
Further, changing the meaning of multiple cert and key options (from last one replaces previous to each adds a new cert/key) would be a regression and potentially break some existing configs.
I still wonder what the use case for this is?
I find this option useful when clients have different algorithm preferences. Part of the algorithm may have been disabled when the client compiled, especially if hardware algorithms are used through the engine configure. Some hardware is only designed to improve algorithm performance, and supports limited algorithms.
I am not sure this even works for TLS 1.3.
For OpenSSL, this works for TLS1.3 through calling SSL_CTX_set1_sigalgs_list() to set the signature algorithms extension in Client Hello. But OpenVPN does not seem to support this configuration yet. So I used TLS1.2 tests
If a device cannot do certain signatures, then the same is true for the CA signing the server cert and you would need also need a different CA. And to actually having to provide to different sets, you need a server that can do soemthing like sigA and sigB and you have clients that can only do sigA and clients that can only do SigB. Otherwise you could just pick one of your two sets of certificates.
To be honest, in order to accept this rather bizzare use of TLS (I am not aware of seeing something like this before), we need a much stronger reason or use than "I find this useful"
For OpenSSL TLS 1.3, I don't think it is a good idea to let the user configure SSL_CTX_set1_sigalgs_list. We already have tls-groups and tls-cipher and tls-cert-profile that influence the signature algorithms that OpenSSL is willing to use on a higher level that is still very low level for most users.
If a device cannot do certain signatures, then the same is true for the CA signing the server cert and you would need also need a different CA. And to actually having to provide to different sets, you need a server that can do soemthing like sigA and sigB and you have clients that can only do sigA and clients that can only do SigB. Otherwise you could just pick one of your two sets of certificates.
Yes, the server needs to configure multiple CA in this case.
we need a much stronger reason or use than "I find this useful"
Both the client and the server have the right to choose the signature algorithm to use for the handshake, how about this.
We already have tls-groups and tls-cipher and tls-cert-profile
TLS1.2 cipher suite includes signature algorithm, but TLS1.3 not. Therefore, tls-cipher cannot be used to configure the signature algorithm used in TLS1.3, tls-cert-profile neither. The status of TLS1.3 is indicated here just to show that the needs of select a signature algorithm does not exist only in TLS1.2.
@jntass This is all very abstract. Can you name a scenario where you actually need this.
- A scenario with concrete algorithms and client where you actually need this featue and cannot have a common CA for all clients. If we accept and maintain this feature we need a way to test and verify that this feature actually works. And so I don't have a sceario for which this feature is needed. Only a hacky way by changing tls-cipher and limiting to TLS 1.2 to trigger the feature. That does not feel particulary useful. Especially since it is TLS 1.2 only.
Both the client and the server have the right to choose the signature algorithm to use for the handshake
Currently the idea is rather the server chooses. That has been the case for lastest features that we implemented (e.g. data channel negotiation). I do see why this is different. Client offers the algorithms it can do and the server picks the preferred one.
Part of the algorithm may have been disabled when the client compiled, especially if hardware algorithms are used through the engine configure.
This is my current scenario. If only a single certificate is configured on the server, some clients may fail to handshake. And due to the TLS1.3 cipher suite definition changes, I cannot configure the signature algorithm during the SSL handshake using the tls-cipher option. Then I downgraded to TLS1.2.
So there are only two ways to test. First downgrade to TLS1.2 and use tls-cipher option, Second support for configuring the signature algorithm extension in client hello and using TLS1.3. It seems that the second way is better, but this introduces a new option. I think there is value in that. The tls-cipher option may not be sufficient due to TLS1.3 cipher suite no longer contains signature algorithm. This option is necessary even if the server chooses.
"some clients fail". Can you be more concrete? I have a hard time figuring out what these clients are that fail unless you manually configured them in a way that they fail.
I will summarise why I am currently thinking. These are the reasons that block your patch from being included (that is my personal opinion, other team member might have other opinions):
- no convincing scenario where this is actually needed. Only vague client description or deliberately misconfigured clients given as example.
- if we cannot understand why this feature is needed, we cannot test it and we cannot maintain, and therefore including it, has to pass a higher bar.
- Does not work for TLS 1.3 (or is not the issue an with TLS 1.3?). And a TLS 1.2 only feature feels not really like a good idea.
- Documentation missing and as @selvanair noted changing the semantics of
certandkeyis not good.
Scenario as follows
"some clients fail"
All of my clients use device through the engine option. Due to device limitations, some of them support only the ECDSA signature algorithm, while others support only the RSA signature algorithm. So I need to limit the signature algorithms that are supported in the client configuration.
Does not work for TLS 1.3 (or is not the issue an with TLS 1.3?). And a TLS 1.2 only feature feels not really like a good idea.
Regarding tls1.3, as mentioned above I can add another option on this PR to support this feature. If you think it necessary.
Still too vague to convince me. What are these mysterious devices that can do ECDSA or RSA only? The only restriction that I am aware of that can do ECDSA but not RSA are devices that are configured to ahdere to NIST Suite B. But in that case you want the server also to be in Suite B mode which prohibits having RSA certificates there as well.
Furthermore, if the goal is really to support client with only a restricted subnet with cipher, your statements about TLS 1.3 are contradactionary. As TLS 1.3 chooses them indendepently and your devices will only announce what they support, why do need something for TLS 1.3 then to still restrict it and offering a PR for it when it should be working without that. Or at least does not address the problem that you are describing that you are trying to solve.
I have to be honest here. It feels that you really want this feature in OpenVPN and probably have a good reason for it. But I get also the feeling that you are not telling me the whole story here. This has two effects. First I am annoyed by that (perceived) attitude and second I am not really convinced by the use case you are trying to make, as it is vague and feel like a theorectical problem rather than a real one.
Sorry for not telling the whole story. What I really need is to configure both SM2 certificate(Actually dual SM2 certificates) and RSA certificate, SM2 algorithm is a kind of ECC curve and is the national standard of China. To do SSL VPN, only by configuring dual SM2 certificates can it comply with the regulations. Then it can authenticate some users through SM2 certificate and some users through RSA certificate. This is a feature specific to Chinese users. Support both ECDSA and RSA is an incidental feature.
The real scenario is to replace the ECDSA in the image above with SM2. SM2 is necessary in some cases in China.
Is there something preventing you from simply running two servers, one for each certificate?
Most scenarios are one port, and it is difficult to open a new port on the cloud. Some of the other open source projects(nginx, httpd etc) I've used with support configuring multiple certificates, so maybe OpenVPN can support this as well.
@jntass as indicated before by @selvanair to include this feature your patch needs improvements to be considered. And you also mentioned that this only works with TLS 1.2 and not with TLS 1.3. So your patch needs to improved to also support TLS 1.3. A feature that is TLS 1.2 only and does not work unless you disable TLS 1.3, is extremely unlikely to be included.
Closing as the patch as is cannot be accepted. Should an improved version be developed, please send it directly to our mailing list for discussion.
