I am facing issues with some external links getting removed by the link checker.
While checking in /etc/linkchecker.html , it shows the links are invalid and throwing a SSL error. The same url works fine in the 6.2 environment. I have not made any modifications to the link checker configurations in either environment. Kindly let me know if any new changes to the 6.4 link checker service might be causing this and how to go about resolving the URL ? I am hoping not to disable the checker altogether.
What's the message in the log about this "SSL error", can you be more specific. I doubt that there is a regression, but my first bet is that your AEM 6.4 environment is configured differently than your AEM 6.2 environment. Maybe missing SSL certificates?
Sorry, I tried to add a picture attachment and it may have got deleted earlier. When I access /etc/linkchecker.html, this is the error I get
Also, I get the below error log for an 'Invalid' and 'Valid' link respectively.
25.07.2018 01:06:46.465 *ERROR* [sling-default-3-com.day.cq.rewriter.linkchecker.impl.LinkCheckerTask.23680] com.day.cq.rewriter.linkchecker.impl.LinkCheckerTask Failed to validate URL http://xxxxyyyzzz.com/xyz/overview.aspx: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
25.07.2018 01:06:47.155 *INFO* [sling-default-3-com.day.cq.rewriter.linkchecker.impl.LinkCheckerTask.23680] com.day.cq.rewriter.linkchecker.impl.LinkCheckerTask Checked URL http://aaabbbccc.com/us/qqqqq.html: 404 (invalid)
All this is happening on my local instance, so there are no certificates etc installed for this.
The problem is this:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
This means, that based on the certificates available to your AEM instance it was not possible to validate the trust chain for a given SSL certificate. Check the certificate in your browser and validate that all intermediate certificates are available to your AEM instance.
Sorry, I did not get the part about validating intermediate certificates on my local AEM instance. Did you refer to enabling SSL on AEM ? I tried creating a https://localhost:8443/ secure URL with self-signed certificates via OpenSSL along with the http://localhost:4502/ . Still facing the same issue.
Just a consideration related to this. AEM authors can use any https URL to build their contents. These https URLs may use some certificates that are not included in the AEM instance. We, as AEM administrators, cannot know which of these certificates will be required in the future for the links included by the authors.
In the other hand, I think we can consider the links are valid, as the end user will find a server response from these links, having a trusted certificate chain or not. The browser will show the typical SSL warnings to the users, and they will be able to choose what to do.
IMHO, I think Link Checker should not check the certificate chain, or it should be an option to enable/disable this behavior. Is there any way to disable the certificate chain validation?
Let me know your thoughts on this issue.
That's a good approach to think about. Can you raise it as a feature request via the Adobe support channels? I don't think that it's available as feature already.
Another thought is, that in reality the number of root certificates for public facing websites is rather limited. The JVM already comes with a good number of them, and they rarely change. Adding a single certificate (maybe your own intranet-based systems where you use your own proprietary root certificate) shouldn't be too hard.
Hello Jörg Hoh ,
I am facing the same issue mentioned above. Obtaining a new valid certificate is not an option as it takes a few months and the client requires this urgently.
In previous versions, the LinkChecker was ignoring this SSL issue via the service.check_override_patterns property, which had been working for some years now. This seems to be an issue with 6.4 only, so I would kindly appreciate your support. Is this a regression?
After a lot of trial and error, we found that the dialog doesn't support space-separated patterns anymore (so the dialog description is a bit misleading -- should it be updated?). Patterns should then be arranged in separate lines in the dialog, and as an array in the config file:
This is the .config that finally worked for us, leaving it here in case someone else runs into the same issue:
Thanks a lot,
good to know. But I truly believe that this was the default behavior ever since. Because this property is a multi-value property in OSGI, and these were always separated as you do now.
And yes, the description is probably misleading quite a lot 🙂 Can you open a ticket with Adobe support, point this out and ask for this to get corrected?