Troubleshoot Certificate Revocation Lookups

In this article we investigate an issue related to LetsEncrypt certificates configured for your web applications and services.

Background

Every so often we would notice in our non-production environment the custom contact forms would fail after the user submitted. These forms are built on top of Sitecore MVC and seemed to fail when the backend code attempted to POST to a service hosted by another team/party.

The error message we would see logged in the Sitecore log files looked like the following:

There are a few resources available online that describe possible causes for the error message and ultimately provide some kind of workaround to the problem.

The remote certificate is invalid according to the validation procedure.

• https://stackoverflow.com/questions/2675133/c-sharp-ignore-certificate-errors
• https://stackoverflow.com/a/66882479/1277533

Research

When reviewing our network we could not find anything that immediately stood out as the cause of the issue. If you make the assumption that calls to the web service are not yet happening, then the next logical thing to investigate are the steps .Net performs prior to making the outbound requests. 

I first confirmed that the web service URL can be reached. In my case the service has a URL to the Swagger UI available and that worked as expected. Second I checked that the LetsEncrypt root certificate was installed in the Trusted Root of the server; which it was. Finally, I used the certutil to verify the certificate which revealed some interesting results.

Running the utility output some key information we needed to determine next steps. As you can see in each of the following screenshots, the lencr.org domain is being accessed. Turns out that LetsEncrypt has a series of domains used to verify if a certificate is revoked. Read here for more details.

Resolution

Ultimately we had the Network/Security Teams put in place firewall rules to allow traffic to the various domains outlined here.

• *.o.lencr.org
• *.i.lencr.org
• *.c.lencr.org

I hope you found this useful. One day you too might be investigating such a rare and peculiar issue. Good luck!

Working with Unicorn and Sitecore CLI

 In this article we learn about some challenges I faced while working with both Unicorn and Sitecore CLI.

On my project we are at a stage in which a wholesale change from Unicorn to Sitecore CLI is not an option. There is however an advantage of updating the deployment pipeline to leverage the IAR plugin for the Sitecore CLI. Our current setup takes upwards of 30 minutes to complete the deployment. Imagine a folder of 40k Unicorn items and trying to zip that up, cleaning the old ones, extracting on the destination server, and then syncing items after every deployment. Deployment nights are exhausting.

Here is a brief list of issues I uncovered along the way.

• Minor issues in YAML compatibility between Unicorn/Rainbow and Sitecore Rainbow.
• Content of YAML may cause the creation of Items in Sitecore without a language version.

YAML Compatibility

The majority of the team is still relying on Unicorn to serialize content to disk. If you use Sitecore CLI to also serialize items, including overwriting files previously serialized by Unicorn, you'll notice some fields missing.

In the following partial example, if this was generated by the Sitecore CLI the database name would be missing which could cause an issue with Unicorn.

In the following partial example, if this was generated by the Sitecore CLI the Multilist field type would be missing which causes Unicorn to sync the fields without the pipe delimiter.

Recommendation: If you are going to also use the Sitecore CLI to serialize items, take note of what fields go missing and make sure they are added back.

The command used with the Sitecore CLI to generate IAR items would be one of the following:

• Sitecore CLI Module -> dotnet sitecore itemres create -o _out/scms -i Scms.* --overwrite
• Unicorn Folder -> dotnet sitecore itemres unicorn -o _out/scms -p "../Serialization" --overwrite

Language Versions

Most installations of Unicorn will exclude several fields such as __Revision. This missing from the serialized items (both in IAR form and YAML) may cause the Sitecore Publishing Service to improperly delete items during publishing. Due to this issue both SXA and SPE now include the revisions in the IAR files.

Another interesting discovery is how few fields you may see listed under each language version. In some files generated by Unicorn I noticed no fields listed under the version. Not sure if this was a mistake during developers merging or something else.

In other cases I found by excluding fields in the sitecore.json as seen in the official docs the YAML serialization and IAR generation will result in fields missing as well. The one time I actually read the manual I end up introducing an issue. (sitecore.json fields removed for brevity)

With the above configuration all the fields serialized are excluded when interacting with the Sitecore CLI. This certainly becomes an issue for items without other fields (like folders).

No fields equals no language version. No Language version equals a broken SPS. Kittens will cry. Ice cream will melt.

Recommendation: Update Unicorn.config to serialize with the __Revision field and then reserialize everything. An issue was opened with Unicorn to alter the patching behavior but for now you may wish to make the change directly for now by manually commenting out the line in the file here.

Run the following SPE report for finding problematic items. Uncomment the section related to language versions missing.