cli-microsoft365: Bug report: Axios doesn't seem to use custom CA certificates

@melcloud - have you looked into this Axios issue: https://github.com/axios/axios/issues/3005? What file are you using? Are you sure it is the root cert? And finally what’s between SharePoint Online and your app, that replaces the certificate?

We can definitely look into it once we have #2146 in place and can expose configuring CLI

Not sure about proxy team, need to check. But should be able to get some comparison between those two versions.

Will report back

Good stuff. I agree, this is not a CLI bug but an Axios issue.

Hi all,

Thank you for looking into this. I can get a more detail --debug output on Monday (AEDT), as I don’t have access to the environment during weekend. But the issue is definitely Axios related. I tried a simple Axios request to the sharepoint site without using the cli, and it returned the same 400 error. It works fine with old request library

Not sure about syswide-cas, I can run a quick test. The sharepoint site has multiple level of CA:

Company ROOT CA ----- Company Intermediate CA ----- Custom Site CA

Regards

Thanks for the suggestion @wictorwilen. We could definitely see if syswide-cas makes any difference. Looking at it, it seems like it’s made to support specifying multiple CAs, whereas @melcloud uses a single one. But perhaps there are some subtle differences that would unblock @melcloud.

Another thing I thought of that might be helpful is to create a minimal repro scenario that we could share with the Axios team and see if they have any ideas what might be causing it.

Never mind, I’ve come to the conclusion that there IS something wrong with the configuration of this specific API I am connecting to. I’m taking it up with the developer there.

Would it be a good idea to close this issue? @melcloud, is this in fact solved now?

I’m running into issues with Axios and certificates as well here: axios breaking on ‘Unable to verify the first certificate’ Postman shows the same exception by the way. the Invoke-WebRequest commandlet and Fiddler have no issues though.

The certificate looks fine. It’s a wildcard certificate issued by DigiCert. All the certs in the chain are OK.

By the way: this is when I execute requests using m365 request at an API endpoint exposed through Azure AD. I have a valid token and can call the endpoint fine with Invoke-WebRequest.

Thank you for the research on this @melcloud 👏

I’m rather surprised that this issue has not been resolved as it affects using a proxy.

I think we should look into implementing tunnel workaround as suggested, ideally having it as a configurable setting.

Yes, the access token is valid. That is why curl with the outputed token works.

Interesting, so the request is rejected by your proxy? The TLS handshake must be successful, otherwise you would not get an HTTP error. Any chance you could work with your proxy team and see why they are blocking this? Might be differences in headers/formatting in Axios vs request? Wireshark or Fiddler might reveal that - which would be interesting to see a comparison of! If you could get a network trace comparing the old CLI vs the new CLI versions that would help tremendously.

Appreciate your help @melcloud. The more information we have about it, the easier it will be for us to find the root cause and ideally a solution.

@melcloud - can you share more of the exception than just the HTTP status code (400). What is the actual URL being queried, what is the full request/response, where is it coming from?

@waldekmastykarz - here’s a package that might be used **if ** we want this to be a part of the CLI: https://github.com/capriza/syswide-cas