JSS headless SSR proxy “unable to verify the first certificate”

When developing a new JSS solution I was looking to have a play locally in headless mode. Unfortunately I hit an issue after standing up a newly minted Sitecore 10 SXA/JSS instance in docker and using it as the apiHost running the node-headless-ssr-proxy sample app locally. After setting up the appropriate values for the proxy and ensuring the react app was in place, I was getting the following error for all SSR layout service requests.

[HPM] Proxy created: /  -> https://xp0cm.localhost
server listening on port 3001!
FetchError: request to https://xp0cm.localhost/sitecore/api/jss/dictionary/jss-sandbox/en?sc_apikey=%7BXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX%7D failed, reason: unable to verify the first certificate
    at ClientRequest.<anonymous> (C:\repos\sandbox\node-proxy\node_modules\node-fetch\lib\index.js:1444:11)
    at ClientRequest.emit (events.js:315:20)
    at TLSSocket.socketErrorListener (_http_client.js:426:9)
    at TLSSocket.emit (events.js:315:20)
    at emitErrorNT (internal/streams/destroy.js:92:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
    at processTicksAndRejections (internal/process/task_queues.js:84:21) {
  type: 'system',
  errno: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE',
  code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE'
}
Read More »

Symposium 2019 – What to look forward to

Sitecore Symposium 2019 is coming up at the Swan and Dolphin* Resort in Orlando, FL.  I live on the other side of the world from Orlando.  Almost literally. It’ll take me just short of 24 hours flight time to get there.  Add in transit and the inevitable delays, it’s over 30+ hours door to door…..each way. I’ll also be leaving a young family and (very understanding) wife at home.  This bit, in particular I am not looking forward to.

But it’s worth it.Read More »

List binary details with powershell

When troubleshooting Sitecore issues and interacting with support there is often a need to confirm the versions of binaries in your solution. While there are tools to help provide all the information, sometimes its just not possible in some environments.

One particular issue we had required a detailed list of the bin folder. Handily the sitecore does write details of all the binaries at startup to the log. Un-handily, if you’re using Application Insights, you’ll likely have the log message truncated as it tends to exceed the 10,000 character trace message size limit.

Unfortunately it’s not as easy as just dir *.dll, as the details required include assembly names and version. But, powershell to the rescue.


get-childitem .\bin\* -include *.dll
| foreach-object { "{0}`t({1},{2})" -f $_, [System.Diagnostics.FileVersionInfo]::GetVersionInfo($_).Comments, [System.Diagnostics.FileVersionInfo]::GetVersionInfo($_).ProductVersion }
| Out-File -filepath assemblies.txt

This will dump the binary details out to a file in the same format as the Sitecore log would’ve done. If you’re on Azure Web apps, you can run this via the powershell console in KUDU. This file can then easily be downloaded then analysed, compared or submitted to support.