RFR: 8202651: Test ActalisCA.java and ComodoCA fails

[Langer, Christoph]

Hi Rajan, Sean,

first of all, thanks for the update on the tests.

As I see, there are still open questions for the ActalisCA test. So I'm wondering whether the fix for ComodoCA can be pushed as fix for https://bugs.openjdk.java.net/browse/JDK-8215546 ?

Furthermore, can we also exclude the ActalisCA test via the ProblemList for the time being? I believe this has not been done because these tests aren't part of any regular test tiers. However, we at SAP run all possible tests in the test folder in some suite of the test environment and it would be good if the test could be excluded then. I would file a bug and do the change if you agree.

Other than that, I'm observing another issue in the CRL test for ActalisCA. It fails with this message: "Received exception: java.security.cert.CertPathValidatorException: sun.security.provider.certpath.PKIX$CertStoreTypeException: Invalid name: cn=Actalis Authentication Root CA,o=Actalis S.p.A./03358520967,c=IT". The problem is that the certificate's issue name is literally taken as javax.naming. CompositeName in LDAPCertStoreImpl. The forward slash symbol '/' is, however, used as component separator in LDAP composite names. So it needs escaping. I'll file a bug and propose a fix for this in a separate thread. I'm actually wondering why this hasn't been reported yet but I don't see similar bugs...

Thank you
Christoph

> -----Original Message-----
> From: security-dev <security-dev-bounces at openjdk.java.net> On Behalf Of
> Rajan Halade
> Sent: Mittwoch, 22. Mai 2019 19:35
> To: Sean Mullan <sean.mullan at oracle.com>
> Cc: security-dev <security-dev at openjdk.java.net>
> Subject: Re: RFR: 8202651: Test ActalisCA.java and ComodoCA fails
> 
> On 5/22/19 9:34 AM, Sean Mullan wrote:
> > On 5/22/19 12:04 PM, Rajan Halade wrote:
> >> On 5/22/19 8:39 AM, Sean Mullan wrote:
> >>> On 5/21/19 5:31 PM, Rajan Halade wrote:
> >>>> Please review this fix to update test certificates used in Actalis
> >>>> and Comodo CA interop tests. The bug also mentioned QuoVadisCA
> test
> >>>> but I am not able to reproduce the failure. For Actalis CA, I
> >>>> couldn't get revoked test certificate but the test is updated for
> >>>> valid certificate and will pass now by skipping expired revoked chain.
> >>>
> >>> It looks like the test is still expecting a revoked status - is that
> >>> still working because the IntCA is revoked?:
> >> It is working because revoked certificate is expired, test is skipped
> >> then.
> >
> > Have you asked Actalis for a new revoked test certificate? If you
> > can't get one, I would remove the revoked certificates and the test
> > for it then, since you are not testing that behavior anymore and that
> > is not apparent from the test right now.
> I will follow up with CA then and leave this bug open for now.
> >
> > Also do you know why the revocation check for the intermediate CA is
> > not working?
> Revocation check on intermediate CA is working fine. INT_REVOKED is a
> good certificate, may name is misleading. INT_REVOKED here means that
> this is a intermediate CA for revoked EE certificate.
> 
> Thanks,
> Rajan
> >
> >>>
> >>>  232         // Validate Revoked
> >>>  233         pathValidator.validate(new String[]{REVOKED, INT_REVOKED},
> >>>  234                 ValidatePathWithParams.Status.REVOKED,
> >>>  235                 "Fri Jan 29 01:06:42 PST 2016", System.out);
> >>>  236
> >>>
> >>> It should be ok if the revoked certificate is expired though as you
> >>> can set the validation date to the past (within the interval where
> >>> the certificate is still valid).
> >>> Or is it because the Actalis OCSP responder is no longer reporting
> >>> that the certificate is revoked?
> >> Earlier test had past validation with OCSP but for some time now OCSP
> >> is returning UNKNOWN status instead of REVOKED. This could be an
> >> issue depending on how implementation treats UNKNOWN status. We
> will
> >> have to follow up with CA to check on policy - Is this only happening
> >> because we are using test certificate or is it a policy?
> >
> > It depends, if it is a TLS certificate then it is usually acceptable
> > to report the revoked certificate as UNKNOWN after it expires since
> > you should not be trusting expired TLS certificates. For a code
> > signing certificate, it is better to retain the REVOKED status for a
> > longer time period after it expires since it may still be in use (for
> > example, in a timestamped application).
> >
> > --Sean
> >
> >>
> >> Thanks,
> >> Rajan
> >>>
> >>> --Sean
> >>>
> >>>>
> >>>> Webrev: http://cr.openjdk.java.net/~rhalade/8202651/webrev.00/
> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202651
> >>>>
> >>>> Thanks,
> >>>> Rajan
> >>