[ 
https://issues.apache.org/jira/browse/WAGON-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241986#comment-16241986
 ] 

André Döblitz edited comment on WAGON-452 at 11/7/17 1:25 PM:
--------------------------------------------------------------

Hello,
sadly my company was late to renew their ssl certificates, so i had to use 
-Dmaven.wagon.http.ssl.insecure=true 
-Dmaven.wagon.http.ssl.ignore.validity.dates=true.
More sadly this did not work in the latest maven release.

maven.wagon.http.ssl.ignore.validity.dates builds up on 
maven.wagon.http.ssl.insecure.

If insecure is true, then RelaxedTrustStrategy is created as TrustStrategy and 
validity.dates gets evaluated.

RelaxedTrustStrategy checkmethod checks exactly one certificate and catches 
expiry-exception and throws it further if validity.dates is false.
If validity.dates is true, the certificate check returns true.

Later, depending on the TrustStrategy, RelaxedTrustStrategy checkmethod gets 
evaluated.
If it returns true, no further checks are done. (So if validity.dates should be 
ignored, it returns true on an expired certificate.)
But if it returns false, then sun.security.validator continues with further 
checks.

sun.security.validator should not throw any ExpiryException when both flags are 
set true.
In my case the Artifactory server had 3 certificates, so RelaxedTrustStrategy 
checkmethod always returned false, because "if (  certificates  != null && 
certificates == 1 )"

I changed it to check all given certificates.
This works, any Exception will be handled in a proper way.
But I dont know why the author intentionally limited the method to exactly 1 
certificate.


was (Author: donnydepp):
Hello,
sadly my company was late to renew their ssl certificates, so i had to use 
-Dmaven.wagon.http.ssl.insecure=true 
-Dmaven.wagon.http.ssl.ignore.validity.dates=true.
More sadly this did not work in the latest maven release.

maven.wagon.http.ssl.ignore.validity.dates builds up on 
maven.wagon.http.ssl.insecure.

If insecure is true, then RelaxedTrustStrategy is created as TrustStrategy and 
validity.dates gets evaluated.

RelaxedTrustStrategy checkmethod checks exactly one certificate and catches 
expiry-exception and throws it further if validity.dates is false.
If validity.dates is true, the certificate check returns true.

Later, depending on the TrustStrategy, RelaxedTrustStrategy checkmethod gets 
evaluated.
If it returns true, no further checks are done. (So if validity.dates should be 
ignored, it returns true with an expired certificate.)
But if it returns false, then sun.security.validator continues with further 
checks.

sun.security.validator should not throw any ExpiryException when both flags are 
set true.
In my case the Artifactory server had 3 certificates, so RelaxedTrustStrategy 
checkmethod always returned false, because "if (  certificates  != null && 
certificates == 1 )"

I changed it to check all given certificates.
This works, any Exception will be handled in a proper way.
But I dont know why the author intentionally limited the method to exactly 1 
certificate.

> Missing exception handling when maven.wagon.http.ssl.ignore.validity.dates 
> flag is set to 'true'
> ------------------------------------------------------------------------------------------------
>
>                 Key: WAGON-452
>                 URL: https://issues.apache.org/jira/browse/WAGON-452
>             Project: Maven Wagon
>          Issue Type: Bug
>          Components: wagon-http
>    Affects Versions: 2.10
>            Reporter: Vítor Teixeira
>              Labels: easyfix, maven, security
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> On org.apache.maven.wagon.providers.http.RelaxedTrustStrategy exception 
> handling is missing.
> With maven.wagon.http.ssl.ignore.validity.dates=true the following exception 
> is thrown:
> sun.security.validator.ValidatorException: PKIX path validation failed: 
> java.security.cert.CertPathValidatorException: timestamp check failed: 
> NotAfter: Tue Dec 29 23:59:59 GMT 2015 -> [Help 1]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to