Disable "Acceptable client certificate CA names" on MTLS client connect. #389
Replies: 5 comments 4 replies
-
|
I am not able to understand what you want to configure. Can you give me more context so I can understand your situation? What issue do you have and what would you like to prevent? |
Beta Was this translation helpful? Give feedback.
-
|
For example. Suppose you do not want to inform the client of the trusted certificates that are accepted by the server. Reference: rfc5246 section-7.4.4 |
Beta Was this translation helpful? Give feedback.
-
|
Ah now it is more clear. Just to clarify, you want to disable the following additional output right: Can you maybe share some test identity and truststores so I can investigate possible configurations? I think it is possible, however I am not able to reproduce the server output which you have as I have different keystores. Looking forward to your respons |
Beta Was this translation helpful? Give feedback.
-
|
Keystore example with CA and server certificate: Truststore example with CA and client certificate DN "[email protected]": Sorry but I cannot attach the keystore. I send them to you in base64. base64 --decode /path/to/file > keystore.p12Password for keystores "changeit". You can try these keystores with the Jetty implementation that I defined at the beginning of this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, with the keystores you shared I was able to reproduce it on my side. I found a way to hide away those 
The library itself does not yet provide such options yet, although a workaround is possible. I will add this option in the future as it seems like a nice feature. For now you can use a workaround. The What you first need is to have this custom TrustManager: public class MyDelegatingTrustManager extends X509ExtendedTrustManager {
private final X509ExtendedTrustManager innerTrustManager;
MyDelegatingTrustManager(X509ExtendedTrustManager innerTrustManager) {
this.innerTrustManager = innerTrustManager;
}
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType, Socket socket) throws CertificateException {
innerTrustManager.checkClientTrusted(chain, authType, socket);
}
@Override
public void checkServerTrusted(X509Certificate[] chain, String authType, Socket socket) throws CertificateException {
innerTrustManager.checkServerTrusted(chain, authType, socket);
}
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType, SSLEngine engine) throws CertificateException {
innerTrustManager.checkClientTrusted(chain, authType, engine);
}
@Override
public void checkServerTrusted(X509Certificate[] chain, String authType, SSLEngine engine) throws CertificateException {
innerTrustManager.checkServerTrusted(chain, authType, engine);
}
@Override
public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
innerTrustManager.checkClientTrusted(chain, authType);
}
@Override
public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
innerTrustManager.checkServerTrusted(chain, authType);
}
@Override
public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[0];
}
}This custom trustmanager returns an empty array of accepted issuers, see the method @Bean
public SSLFactory sslFactory(@Value("${ssl.keystore-path}") String keyStorePath,
@Value("${ssl.keystore-password}") String keyStorePassword,
@Value("${ssl.truststore-path}") String trustStorePath,
@Value("${ssl.truststore-password}") String trustStorePassword)
throws Exception {
KeyStore trustStore = KeyStoreUtils.loadKeyStore(trustStorePath, trustStorePassword.toCharArray());
X509ExtendedTrustManager trustManager = TrustManagerUtils.createTrustManager(keyStore);
return SSLFactory.builder()
.withIdentityMaterial(identityKeystore.toPath(), keyStorePassword.toCharArray())
.withTrustMaterial(new MyDelegatingTrustManager(trustManager)) // here we wrap the actual trustmanager with our custom one
.withSwappableIdentityMaterial().withSwappableTrustMaterial()
.withNeedClientAuthentication(Boolean.TRUE)
.withProtocols("TLSv1.3", "TLSv1.2")
.withCiphers("TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384", "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384")
.withSessionTimeout(3600).withSessionCacheSize(1024).build();
}It is a bit verbose, but can you give it a try on your side and share the results? If this is what you are looking for we can add it in the next version of the library. |
Beta Was this translation helpful? Give feedback.
-
|
Your solution is working perfectly :-) Partial reponse: ...
---
Server certificate
subject=CN = ssl-server-cert
issuer=CN = ssl-ca-cert
---
No client certificate CA names sent
Client Certificate Types: ECDSA sign, RSA sign, DSA sign
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:DSA+SHA256:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:ECDSA+SHA1:RSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:DSA+SHA256:ECDSA+SHA224:RSA+SHA224:DSA+SHA224
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2067 bytes and written 472 bytes
Verification error: self-signed certificate in certificate chain
---
...Thank you very much for your help and work :-) |
Beta Was this translation helpful? Give feedback.
-
|
I have reopened the discussion because I have detected a flaw with the solution you have proposed. Flow: Command openssl s_client -showcerts -servername 127.0.0.1 -connect 127.0.0.1:8443 </dev/null |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the workaround is not compatible when you use it with the swappable option. No worries, I am working on a native implementation so you don't need to have custom configuration on your side. Can you have a look at this pull request please: #392 I think it is more clean in this way, but lets try to improve it together wherever it needs to be polished. See also my comment on the pull request for the example usage. |
Beta Was this translation helpful? Give feedback.
-
|
you are really fast ... |
Beta Was this translation helpful? Give feedback.
-
In MTLS configuration, by default, all allowed clients CN are returned when a client initializes an SSL communication. This can lead to many security risks and information leaks.
This is my server implementation:
Command to check issue:
openssl s_client -showcerts -servername 127.0.0.1 -connect 127.0.0.1:8443 </dev/nulPartial reponse:
How can I disable the response of allowed clients in the truststore file?
Best regards :-)
Beta Was this translation helpful? Give feedback.
All reactions