I am using Mamp Pro 5 and last week I can set up and using SSL by generated a self-signed certificate.
But today when I am trying to start server again, it is doesn't work anymore. I checked on log files and it said : [Sat Oct 12 13:36:58 2019] [error] (1)Operation not permitted: Init: Can't open server certificate file (path to file)/uf.o.crt
Please let me know how to fix this.
Thanks
This is a screenshot of error log.
Move the SSL certificates into the default MAMP certificates folder:
/Applications/MAMP/Library/OpenSSL/certs/
I have experienced the same problem after upgrading MacOS 10.15 Catalina to build 19A602 (security updates from yesterday). I used to store self created SSL Certs in my user folder and apache could not be started any more.
After moving all .crt and .key files into the folder where MAMP itself stores it's automatically generated certificates (which is /Applications/MAMP/Library/OpenSSL/certs) the problem was gone.
Of course you will have to check every single host and re-link certificate files (marked with a red exclamation mark) to make it work - but no need to completely uninstall MAMP
Usually this problem appears after upgrading MacOS.
Disable Apache
Disable SSL in MAMP
Start Apache
Disable Apache
Enable SSL in MAMP and generate new SSL certificate
Start Apache
It works for me :)
I just solved it by myself and I also got this solutions from developers after I solved it.
What I did is just full uninstall Mamp and try to install it again.
That's all fixed.
I had similar issue and solved this by moving my all projects under my home folder. SSL certificates were regenerated (I use MAMP Pro and prefer to keep ssl certs under my projects for development purpose)
With MAMP PRO 6, certificates are managed by MAMP. I had a problem with a certificate that was expired. I simply deleted the host and recreated the host afterwards. MAMP has generated new certificates and everything is ok.
Related
I created a self-signed certificate in a local pc and now I can't access to the localhost showing the following error in both chrome & firefox. There is no option to accept the risk and continue.
I tried removing the generated cert and key files but the issue is still there.
Is there way to rollback that change? Or any other way to continue.
OS: OpenSUSE Thumbleweed
HSTS is blocking you, so clear HSTS config in used browser for used domain (locahost). Random blog post how to do that: https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/
Previously I used RapidSSL certificate. After it expired I moved to Lets Encrypt (free ssl) and installed on my server. But site uses still old SQL certificate after couple of refreshes taking new SSL certificate and resources (css, images, scripts) are not loading gives NET::ERR_CERT_DATE_INVALID error.
I restarted Apache couple of times.
I'm using Ubuntu 16.04.
NET::ERR_CERT_DATE_INVALID means your SSL certificate date is invalid, that is because your old certificate has expired. Check your apache config to make sure that - certificate files mentioned are the desired ones. For detail debugging of your problem, you need to look at your apache server log could be located at /var/log/apache2.
This is my first time using WAMP I had to remove expired certificates from WAMP I just replaced my certificates in ssl certificate folder, I replaced my privatekey with the privatekey From primary domain webserver(GoDaddy Apache) and tried to restart the WAMP services It does not restart anymore.
The error That is present in Event Viewer is
The wampapache service terminated with service-specific error Incorrect function..
This must be a noob question. But what can I do to install the new certificates(Please note the WAMP server is serving my subdomain).
What am I missing?Help would be appreciated very much.
The solution was in the config file. The previous team messed up naming files in them.
I recently changed my certificate to LetsEncrypt's.
I placed the new certificate in the location of the old one:
cat /etc/haproxy/certs/fullchain.pem /etc/haproxy/certs/privkey.pem > /etc/haproxy/certs/mydomain.com.pem
And in my haproxy.cfg I have:
frontend https
bind :::8443 v4v6 ssl crt /etc/haproxy/certs/mydomain.com.pem no-sslv3
Then I ran systemctl reload haproxy, but it still brings the old one when I access it in my browser or using SSLLabs.
If I use curl -kv mydomain.com it shows the correct certificate.
I had this same issue where even after reloading the config, haproxy would randomly serve old certs. After looking around for many days the issue was that "reload" operation created a new process without killing the old one. The old processes were serving the outdated certs. You can check this by "ps aux | grep haproxy".
Fix
If your environment allows for a few seconds of downtime run "service haproxy stop" until no haproxy processes are left and then start haproxy.
**OR**
Sort by starting time and kill old processes while checking if the service is still running in between.
1 Year later EDIT
Instead of manually doing the fix mentioned above after every reload, we added a "hard-stop-after" for 600 seconds. Made sure to kill all old processes after adding the param and checked the same using ps aux. So now, older processes have to die after 600 seconds, and cannot serve outdated certs.
If you have the old pem file in /etc/haproxy/certs, HAproxy might be using it instead of new one.
I had a similar problem. HAproxy was using expired certificate that was first created for only dev.domain.com with Let's Encrypt. Later I changed certificate creation process to include multiple domains:
domain.dom www.domain.com and dev.domain.com.
The old dev.domain.com.pem was still in /etc/haproxy/certs folder. When I visited https://dev.domain.com, HAproxy used old pem certificate file and Chrome issued a warning for expired certificate.
When I deleted dev.domain.com.pem file and reloaded HAproxy, it started using new certificate and SSL is working correctly again.
My problem was historic and outdated wildcard cert that HAProxy (HA-Proxy version 1.8.19-1+deb10u3 2020/08/01) erroneously picked up and spitted out as outdated subdomain cert, both in the browser and in cURL.
Reloading, restarting, stopping+starting and even upgrading Debian did not help. What did help was to remove the outdated wildcard cert and reload.
I have installed a new certificate on an existing webserver.
Ran "https://www.sslshopper.com/ssl-checker.html". says the certificate
is 700+ days old.
The domain is "www.infocon-inc.com"
Certificate is SHA2.
Created a free certificated made sure sha256.
using both the configure file and the command line -sha256.
running Apache 2.2+ with openssl 1+
Checked IP Address
checked the firewall https is open port.
restart Apache, everytime I updated the certificate.
Still get "ERR_CERT_AUTHORITY_INVALID" error in the browser.
Site has been up for years.
Any ideas as to where to look for the problem?
The problem was there was in ssl.conf referenced localhost.crt and localhost.key.