Hi,
I have updated the Release Notes Drop 2, after the update I found the difference while build locally, it change to https. i.e - Warning - [serve] When serving in HTTPS mode, a PFX cert path or a cert path and a key path must be provided. If a SSL certificate isn't provided, a default, self-signed certificate will be used. Expect browser security warnings.
After this I try to open the webpart in SharePoint it still pointing the http URL attached the screen shot FYR.
You're talking about a SharePoint-hosted workbench.aspx, right? That workbench tries both HTTPS and HTTP (it tries HTTP last, which is why you see the error specifically pointing out HTTP).
The issue is probably that you haven't trusted the self-signed cert. While running gulp serve, try navigating to a served URL in a browser and trusting the cert on both localhost and on a URL pointing to your machine name. i.e. - go to both https://localhost:4321/temp/manifests.js and https://<your-machine-name>:4321/temp/manifests.js and click through to trust the cert on each.
Thank you very much @iclanton It is fixed.
Was about to throw machine out of window after days of it not working but after several repeated attempts the suggestion from @iclanton fixed it in Firefox at least.
Now to try and get it working on my home machine.
Glad it worked! We're working on improving the SSL story for the next drop so this won't be as painful.
Hi,
Even after following the above steps doesnt solve the problem for me, I am on Windows 10. I could install the certificate multiple times and the result is the same, please help!
it works for me on Chrome, thanks
This really needs to be addressed, far too many gotchas and kludgy workarounds to make any of this useful
The magical hidden setting for ignoring insecure certificates is found here chrome://flags/#allow-insecure-localhost I can now make this work...but again, this is really a pain...and if I have to hold the hands of my developers to get their environments to work AND support them when it doesn't work...then all time saved with the new framework is for nothing.
Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues
Most helpful comment
The magical hidden setting for ignoring insecure certificates is found here chrome://flags/#allow-insecure-localhost I can now make this work...but again, this is really a pain...and if I have to hold the hands of my developers to get their environments to work AND support them when it doesn't work...then all time saved with the new framework is for nothing.