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:
Buy a 100% valid SSL certificate for *.dev.myapp.com or dev.myapp.com (they cost very little) - best deals I know of are from ssls.com
Deploy that on your development VMs, or in your repository and configure your apps to use it the same way you configure your production environment to use that certificate (generally terminating it to Nginx/HAProxy/similar)
Configure the VMs with hosts entries so api.dev.myapp.com or whatever else you have point to 127.0.0.1
Configure the hosts entries on the host machine either manually or via something like vagrant-hostsupdater
No 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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.