Expand my Community achievements bar.

Learn about Edge Delivery Services in upcoming GEM session

AEM 6.4 Link Checker SSL Error

Avatar

Level 2

Hi,

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.

13 Replies

Avatar

Level 10

I will check with cust care team to see if this is a known issue.

Avatar

Employee Advisor

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?

Jörg

Avatar

Level 2

Hi,

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

Link Checker_Question.png

Also, I get the below error log for an 'Invalid' and 'Valid' link respectively.

Invalid :

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

Valid :

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.

Avatar

Employee Advisor

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.

Avatar

Level 2

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.

Avatar

Level 4

Hi Jörg.

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.

Kind regards,

Julio.

Avatar

Employee Advisor

Hi Julio,

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.

Jörg

Avatar

Level 1

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?

Best regards,

Gio

Avatar

Employee Advisor

This property still exists (checked on my local 6.4 env here).

Jörg

Avatar

Level 1

Jörg Hoh Sorry if I wasn't clear. I didn't say it doesn't exist, it's there but it doesn't work properly because it doesn't ignore SSL errors anymore.

Gio

PD. you can see other people are having the same issue with 6.4: Link Checker Issue - SSLException - AEM 6.4

Avatar

Employee Advisor

Hm,

can you post the exception you see? For me it seems that the functionality is unchanged in AEM 6.4

Jörg

Avatar

Level 1

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:

1721510_pastedImage_0.png

This is the .config that finally worked for us, leaving it here in case someone else runs into the same issue:

service.check_override_patterns=["^system/", "^https:\/\/www\.google\.com"]

Thanks a lot,

Gio

Avatar

Employee Advisor

Hi,

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?

Thanks,

Jörg