A good rule of thumb in software development is that you should try to be as close as possible from your production environment. Doing so helps you...
For further actions, you may consider blocking this person and/or reporting abuse
These very few lines of python do it for me with a self signed certificate:
import BaseHTTPServer, SimpleHTTPServer
import ssl
httpd = BaseHTTPServer.HTTPServer(('localhost', 4443), SimpleHTTPServer.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, certfile='./server.pem', server_side=True)
httpd.serve_forever()
FWIW, I made a little cross-platform CLI tool called
tls-keygen. It generates modern localhost certs (ECC, SAN, IPv6, wildcard, ...) and hooks up the OS trust store to satisfy browser security requirements.Give it a try and let me know what you think:
npmjs.com/package/tls-keygen
I'm not even sure what you're advocating after reading this. Instead of simply using self-signed certificates (which are super easy to automate in a Vagrant box) and then using
--ignore-certificate-errors, you're saying you're using several components to achieve the same end result?If it's crucial for you the domain stays the same, I don't understand how your code has been built without such basic configuration ability.
The other option that I can imagine you could be doing based on this, is that you're putting your production SSL certificates on your developers' computers, which is a BAD idea.
Personally my strategy tends to be:
*.dev.myapp.comordev.myapp.com(they cost very little) - best deals I know of are from ssls.comhostsentries soapi.dev.myapp.comor whatever else you have point to127.0.0.1hostsentries on the host machine either manually or via something likevagrant-hostsupdaterNo worrying about self-signed certificates causing errors or having your devs ignore invalid certificates, no worrying about your devs having production certificates, no worrying about difficult complicated processes to follow - you deploy it the same way as to production, just using a different certificate.
After thinking of this a bit more, I really hope you're not saying your devs are running your backend and frontend code directly on their main OS. You're not likely running OSX on your production servers, and that kind of discrepancy alone can lead to issues, even if your devs would never work on any other thing on that same laptop (which is unlikely).
Thanks for the Vagrant tip, part of our stack is on Heroku (small team, rather pay Heroku to deal with Ops) so I'm not sure it would solve the "mirror prod" issue. What we do instead is to use Docker to make sure we all use the same versions of the dependencies (languages and services) and to be as close as possible to the Heroku stack.
We have a monolith for the backend and our frontend on S3 + Cloudfront so our current approach was fitting our use case but I definitely want to switch to proper certificates as soon as possible.
I'm definitely not proud of the --ignore-certificate-errors as it's a risk in itself.
I did some bash scripts to automate this process a while ago. I prefer haproxy for easy of use.
You could check the code here github.com/mariancraciun1983/Dev-C... with a haproxy example.
Another simple solution for local aliasing, would be to have a CNAME for *.localhost.DOMAIN.com point to 127.0.0.1 . This will allow you to have unlimited hostnames.
Seems quite elegant, I'll definitely look into that. Thanks for sharing your code too!
I have the same problem at my job, but we just use webpack-dev-server, it has an option to enable HTTPS. If you enable it and don't provide a certificate it just automatically auto-generates a self-signed one for you which you need to manually allow in your browser or add to your certificate manager. One caveat is that whenever you make a clean npm install it generates a new certificate which you need to allow again.
If your project is not node you should still be able to use it in conjunction with the proxy option to forward requests to another localhost port. This solution would be similar to local-ssl-proxy.
Yes, we got that working out of the box on our React app, but we had to do custom startup scripts for the other services.
It's definitely a great feature.
github.com/FiloSottile/mkcert
Try telebit.cloud
I use Laravel Valet, laravel.com/docs/5.6/valet, which has nginx, dnsmasq setup in a single package with a custom ld, I am using .test
You can get an HTTPS valid site by using the secure option for a site.
backplane.io will solve this for you, and takes less than two minutes to set up.