Marcono1234 commented on code in PR #492:
URL: 
https://github.com/apache/httpcomponents-client/pull/492#discussion_r1355665024


##########
httpclient5/src/test/java/org/apache/hc/client5/http/examples/AsyncClientCustomSSL.java:
##########
@@ -59,6 +59,11 @@ public class AsyncClientCustomSSL {
     public static void main(final String[] args) throws Exception {
         // Trust standard CA and those trusted by our custom strategy
         final SSLContext sslContext = SSLContexts.custom()
+                // Specify a custom TrustStrategy

Review Comment:
   > It is not any more secure, it is just simpler, that is all.
   
   I was thinking in the context of trusted custom CAs, but you are right, 
there might be other cases where using a custom truststore instead of a 
`TrustStrategy` is not necessarily more secure (but probably also not less 
secure?).
   
   > it is just simpler
   
   To me it feels like sadly the opposite is the case; writing a custom 
`TrustStrategy` is easy (even if logic inside it might be complex), compared to 
all the overhead of obtaining the certificate chain of your server as file, 
reading the certificate files, importing them into a `KeyStore`, and then 
specifying the `KeyStore` as truststore.
   
   And if you want to trust the certificate chain *in addition* to the CAs 
trusted by default by the JRE, then it becomes even more complicated because it 
is your responsibility as user to obtain a `KeyStore` containing these JRE root 
CAs and merging them, see [this question](https://stackoverflow.com/q/24555890).
   
   Of course you could also consider modifying the `cacerts` file of the JDK 
installation but that approach is not portable.
   
   > I personally would not phrase it this way, but I can live with it.
   
   Feel free to adjust the changes on this branch (you have write access to 
this branch), or after you merged the changes.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to