Sp-dev-fx-webparts: Workbench not working after chrome update - certificate is broken

Created on 16 May 2017  路  16Comments  路  Source: pnp/sp-dev-fx-webparts

Category

  • [ ] Question
  • [x] Bug
  • [ ] Enhancement

Expected or Desired Behavior

Workbench should work properly in chrome, using the dev certificate.

Observed Behavior

Chrome doesn't trust dev certificate after latest update, showing this error:

Your connection is not private

Attackers might be trying to steal your information from localhost (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID

The reason is, chrome stopped trusting certificate with common name only. to fix this, you will have to build a new certificate and push it as an update to everyone. Currently there is no way to bypass this chrome limitation as far as I checked.

Steps to Reproduce

Update chrome. Try to use the workbench.

Submission Guidelines

_Delete this section after reading_

  • All suggestions or bugs are welcome, please let us know what's on your mind.
  • If you are reporting an issue around any of the samples, please ensure that you have clear reference on the sample and possibly code file, which should be fixed.
  • If you have technical questions about the framework, we鈥檒l be monitoring #spfx, #spfx-webparts, and #spfx-tooling on (SharePoint StackExchange)[http://sharepoint.stackexchange.com/]. You can also alternatively submit your question to (SharePoint Developer group)[https://network.office.com/t5/SharePoint-Developer/bd-p/SharePointDev] at Office Network.
  • Remember to include sufficient details and context.
  • If you have multiple suggestions or bugs please submit them in separate bugs so we can track resolution.

Thanks for your contribution! Sharing is caring.

All 16 comments

Should this topic help you https://github.com/SharePoint/sp-dev-docs/issues/395?
I deleted <OS_homedir>/.gcb-serve-data directory and executed gulp trust-dev-cert according the comments and worked for me.

Hi! My guess that this post by @AndrewConnell might help with.

Yeah, I can create a certificate myself, I just think this bug should be fixed in SPFx as a part of SPFx and not by each developer individually.

This was an update with Chrome 58 (if remember correctly). This issue has been fixed with the latest version of the Yeoman templates. If you re-register dev-cert, you'll be fine. In general, this kind of generic issues would be better to report at https://github.com/SharePoint/sp-dev-docs/issues, which we use also for input/feedback discussion. That issue list is synced directly with our VSO tasks, so things move much faster.

Hi @VesaJuvonen was it fixed in the GA version of Yeoman template, or in the dev beta versions?
As far as I see the issue still exists on GA version.

Thanks

That was fixed in the later version, since Chrome introduced this change back in May (if remember correctly on timing). Would suggest to update to latest Yeoman template version and rerun the cert trust to resolve this. I'm running Chrome and latest version without any issues in Win10.

So, I ran:

npm uninstall -g @microsoft/generator-sharepoint
npm install -g @microsoft/generator-sharepoint@latest
gulp trust-dev-cert

But still no luck, on my existing project gulp serve is broken in chrome.

Should this fix it in existing projects?

Thanks.

hmm - I'm running Chrome v59 currently without any issues. Could you do untrust-dev-cert in the process as well to ensure that we get the old one away. This should fix also old projects based on the testing we did.

I'm on chrome 58, untrust/trust did prompt me to remove/add the certificate but still getting the error on certificate in chrome. I'm surprised not 100 people complaining about this... am I the only one? (Me and my 3 devs)

Updated chrome to 59, same error still.

I even tested this with random VM10 created in Azure - so puzzled. We'll need to investigate this then even more.

Any input I can provide from our machines?
Like I said, we got this on several windows 10 machines.

You need to also update the build tools in your project. This was fixed in sp-build-web version 1.0.1. Can you try updating sp-build-web in your package.json to version 1.0.1? Or, ideally, to the latest version (1.1.0)? After you do that, re-run npm install (or if you want to be super safe, delete node_modules directory and run npm install), and try running gulp serve again. It should prompt you to re-generate your certificate, and the new certificate should fix the problem.

A note for the future - updating the generator package on your machine doesn't migrate existing projects.

Changing to 1.1.0, running npm install give me an error:
Error: EPERM: operation not permitted, rename
path C:\SPFx\dvpnode_modules.staging\@microsoft\loader-load-themed-styles-3e949feb

I will try to delete all my node modules folder and re-run npm install. Is there any other dependency I should modify while I am at it?

Ok, updated all MS dev dependencies to latest, and deleted node_modules folder.

Now - npm install works.

Gulp serve, however, throws a million and one errors that types don't match.

And, I wasn't prompted for a certificate either.

here is my package.json file, can you clarify what should I have?

{ "name": "dvp", "version": "1.0.1", "private": true, "engines": { "node": ">=0.10.0" }, "dependencies": { "@microsoft/sp-client-base": "~1.0.0", "@microsoft/sp-core-library": "~1.0.0", "@microsoft/sp-webpart-base": "~1.0.0", "@types/knockout": "3.4.41", "@types/webpack-env": ">=1.12.1 <1.14.0", "knockout": "3.4.2" }, "devDependencies": { "@microsoft/sp-build-web": "~1.1.0", "@microsoft/sp-module-interfaces": "~1.1.0", "@microsoft/sp-webpart-workbench": "~1.1.0", "@types/chai": ">=3.4.34 <3.6.0", "@types/mocha": ">=2.2.33 <2.6.0", "gulp": "~3.9.1", "knockout-paging": "^0.4.0" }, "scripts": { "build": "gulp bundle", "clean": "gulp clean", "test": "gulp test" } }

Got it to work, finally.

Thanks @iclanton you put me in the right track.

Here are the exact steps I took and what to avoid

Was this page helpful?
0 / 5 - 0 ratings