SSL renew certificate on apache keeps using old certtificate file - apache

I'm trying to renew my SSL certificate but there is some problem i'm probably missing. after i'v done the following steps the server keep using the old certificate and i do'nt know why.
here'w what i have done:
Create new csr file (domain.csr) + key file (domain.key)
openssl req -new -newkey rsa:2048 -nodes -keyout domain.key -out domain.csr
Copy csr file content and paste it to my ssl provider + get approval.
get 5 files from them and upload them to the server (domain.der,domain.pem
,domain.cer, chain.cer , domain.p7b )
set on apache ssl.conf file ,
SSLCertificateFile (domain.cer) SSLCertificateKeyFile (domain.key).
restart apache
for some reason my server is still using my old certificate.
is the something i'm doing wrong?

Well you figured it out yourself but in case anyone else is in same situation, here's some of the things you can check.
First up check locally whether this works, by running the following openssl command on the server (a crucial step we skipped!):
openssl s_client -connect localhost:443
This will show the cert presented to the client from Apache. If that's not the right one, then you know Apache config is at fault. If it is the right one then something downstream is a problem.
In your case you terminate SSL at the load balancer and forgot to change the cert there. Another issue could be browser caching the SSL cert (restart it, Ctrl+F5 to force refresh or better yet try another browser or a third party website like ssllabs.com).
Assuming it's a problem with Apache then you need to check the config to check all instances of the cert have been replace. The below command will show all the vhosts and what config they are configured in:
/usr/local/apache2/bin/apachectl -S
Alternatively just use standard find and grep unix commands to search your Apache config for the old or new cert:
find /usr/local/apache2/conf -name "*.conf" -exec grep olddomain.cer {} \; -print
Both those commands assume apache is installed in /usr/local/apache2 but change the path as appropriate.
If all looks good and you've definitely restarted Apache then you can try a full stop and restart as I have noticed sometimes a graceful restart of Apache doesn't always pick up new config. Before starting the web server back up again, check you can't connect from your browser (to ensure you're connecting to the server you think you're connecting to) and that the process is down with the following command:
ps -ef | grep httpd
and then finally start.
Another thing to check is that the cert you are installing is the one you think it is, using this openssl command to print out the cert details (assuming the cert is in x509 format but there are similar commands for other formats):
openssl x509 -in domain.cer -text
And last but not least check the Apache log files to see if any errors in there. Though would expect that to mean no cert is loaded rather than just the old one.

Good answer from #Barry.
Another aspect is apache is not the front most web server. From this conversation. It is possible that there are other web servers in front of apache.
Something like - nginx. In our case it was AWS ELB. We had to change cert in ELB in order to change.

We had a similiar problem to what #Akshay is saying above.
In order for the server to update the certificates we had to run some commands for Google Cloud Compute Engine Load Balancer:
gcloud compute target-https-proxies update
Hope this helps someone that is using GCP for hosting apache.

Related

Configuring filebeat to graylog with TLS (connection reset)

I have successfully created a graylog server (in docker container) that ingests logs from filebeat on a separate machine.
However I of course would like to have the messages encrypted. I am attempting to set this up however I cannot seem to get graylog to accept the connection, instead it is always being reset by peer:
{"log.level":"error","#timestamp":"2023-01-04T15:08:57.746+0100","log.logger":"publisher_pipeline_output","log.origin":{"file.name":"pipeline/client_worker.go","file.line":150},"message":"Failed to connect to backoff(async(tcp://<graylog_ip>:5044)): read tcp 192.168.178.99:54372-\><graylog_ip>:5044: read: connection reset by peer","service.name":"filebeat","ecs.version":"1.6.0"}
(Without tls the connection works as intended, a new line appears in graylog every time one is added to my test log file.)
Setup Details
I created a filebeat.crt and filebeat.key file with openssl. I confirmed that the hostname for the certificate was the same hostname for the server with graylog on it:
openssl genrsa -out filebeat.key 2048
openssl req -new -x509 -key filebeat.key -out filebeat.crt -days 3650
From my knowledge, a CA should not be required since I have copied the key myself, filebeat can just encrypt the data it sends with the filebeat.crt, then the server can decrypt with filebeat.key (perhaps this is not correct of me to imagine?)
I then copied both files to the server and local machine. In my compose file I mounted the key into the graylog container and restarted. Then I set up the input configuration that was working previously to have:
bind_address: 0.0.0.0
charset_name: UTF-8
no_beats_prefix: false
number_worker_threads: 12
override_source: <empty>
port: 5044
recv_buffer_size: 1048576
tcp_keepalive: false
tls_cert_file: /etc/graylog/server/filebeat.crt
tls_client_auth: disabled
tls_client_auth_cert_file: <empty>
tls_enable: true
tls_key_file: /etc/graylog/server/filebeat.key
tls_key_password: ********
Then in filebeat I have the following configuration (I also tried converting and using filebeat.pem for the certificate, but no change):
output.logstash:
hosts: ["<graylog_ip>:5044"]
ssl.certificate: '/etc/pki/tls/certs/filebeat.crt'
ssl.key: '/etc/pki/tls/private/filebeat.key'
I really cannot see the issue, any help would be greatly appreciated!
First, try to debug filebeat using
/usr/bin/filebeat -e -d '*' -c filebeat_5.1.2.conf
Probably you will discover that CA is needed or something like that.
But my best quess is that filebeat tries to verify hostname and certivicate name, your generated certificate could not have CN identical to hostname.
Proper solution is using:
ssl.verification_mode: none
Well, this solution works for me.

Permanently replacing API server certificates

I have microK8S cluster, and expose the API server at my domain.
The server.crt and server.key in /var/snap/microk8s/1079/certs need to be replaced with the ones that include my domain.
Otherwise, as expected, i get the error:
Unable to connect to the server: x509: certificate is valid for kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster, kubernetes.default.svc.cluster.local, not mydonaim.com
With the help of cert-manager I have produced certificates and replaced them, my system works well.
Problem: every time server is restarted, server.crt and server.key are generated again in
/var/snap/microk8s/1079/certs. My custom certs are deleted, making API server unreachable remotely.
How can I stop the system from doing that all the time?
Workaround?
Should I place my certificates elsewhere and edit config files like /var/snap/microk8s/1079/args/kube-controller-manager with the path to those certificates? Are those config files auto-replaced as well?
Cluster information:
Kubernetes version: 1.16.3
Cloud being used: Bare metal, single-node
cluster Installation method: Ubuntu Server with Snaps
Host OS: Ubuntu 18.04.3 LTS
It looks like there is an existing issue that describes copying and modifying the /var/snap/microk8s/current/certs/csr.conf.template to include any extra IP or DNS entries for the generated certificates
Please be aware of the proposed updates in https://discuss.kubernetes.io/t/services-and-ports/11263/6. The following command was required to run in my env:
sudo microk8s refresh-certs

Manual renewal of let's encrypt certificate

When creating my certificate initially I had to do it manually by running the following command.
sudo certbot certonly --manual -d www.example.com
What is the correct process of renewing the certificate now? Do I simply rerun the same command? I've researched this a bit and the it seems that the automatic renewal is not possible as I had created this certificate manually.
Will renewing the certificate by running the same command create new fullchain.pem, cert.pem, chain.pem and private.pem files. I am asking this because this would require me to update the information on my Compute Engine that is using the certificate I'm trying to renew.
I'm not using certbot, but I used acme-tiny: https://github.com/diafygi/acme-tiny (I found it on Let's Encrypt page)
In the README you can read about renew: Step 6: Setup an auto-renew cronjob
And the conclusion is that renew is only execute again the program with the same files (account key, domain key and csr).
So I supose that if you did a manual request with certbot (I supose that you provide some info like keys) you only need to execute again the command and get your new cert.

Apache no longer server SSL after Yosemite upgrade

After upgrading to Yosemite I am no longer able to use my web server. It was set up to accept SSL connections on port 443, but now netstat -a -n says it isn't even listening on that port. I looked in /etc/apache2 and noticed that extra/ had been moved to original/extra so I moved that back. There was also a copy of httpd.conf in original/ but the timestamp and size was unchanged and diff showed it was identical to my original httpd.conf. The only other file in /etc/apache2 which has a new timestamp is users/ but nothing in that directory is changed.
All my certificate files in ssl/ still have the correct permissions. I don't see anything in /var/log/apache2/error_log (aside from the normal startup messages). In fact, even if I try to access the web server on port 80 I get nothing in either error_log or access_log even though I unexpectedly get 403 Forbidden on every page I try to access.
I have read about problems with Yosemite updating Apache from 2.2 to 2.4, but my web server doesn't even seem to be functional to the point of fixing any error caused by that. In any case, I did try the solution here, but my httpd.conf file does not contain any Order or Allow lines (nor does any file in extra/) so I can't try the answer suggested there.
OK, this is an old topic, but here's an answer.
I believe you have to uncomment a few lines in httpd.conf.
Run:
sudo vi /etc/apache2/httpd.conf
Uncomment the following lines:
#LoadModule ssl_module libexec/apache2/mod_ssl.so
#Include /private/etc/apache2/extra/httpd-ssl.conf
A simple trick is to search the configuration file using VIM to find lines related to SSL and debug from there.
In VIM, the following will find all instances of ssl... press n to go to next found instance:
?ssl
Once you made changes, test your configuration using:
sudo apachectl configtest
If all is good, run:
sudo apachectl restart
If you get the following error:
SSLCertificateFile: file '/private/etc/apache2/server.crt' does not exist or is empty
Create a default self-signed SSL certificate:
cd /private/etc/apache2
openssl req -new -x509 -days 365 -nodes -out server.crt -keyout server.key
Enter localhost when asked for your Common Name.
Then run configtest and, if all is good, restart.

Heroku ssl certs: Key could not be read since it's protected by a passphrase

I am having trouble generating ssl certs that Heroku will accept for secure.mydomain.com. I'm using DNSimple, Cedar Stack, and following the instructions here: https://devcenter.heroku.com/articles/ssl-certificate
Copy server.key & server.orig.crt from DNSimple
Get root CA certificate with $ curl https://knowledge.rapidssl.com/library/VERISIGN/ALL_OTHER/RapidSSL%20Intermediate/RapidSSL_CA_bundle.pem > rapidssl_bundle.pem
Concatenate into one file with cat server.orig.crt rapidssl_bundle.pem > server.crt
So now I have the server.key & server.orig.crt files, which I try to upload to Heroku with $ heroku certs:add server.crt server.key. This gives the error
Key could not be read since it's protected by a passphrase.
The docs above don't mention anything about removing the passphrase from the server.key file. So I dug around and found the docs here: https://devcenter.heroku.com/articles/ssl#customdomain-ssl. I'm running these commands between #1 and #2 above:
1b. $ mv server.key server.orig.key
1c. $ openssl rsa -in server.orig.key -out server.key
However this gives the error
unable to load Private Key
47930:error:0906D06C:PEM routines:PEM_read_bio:no start line:/SourceCache/OpenSSL098/OpenSSL098-47/src/crypto/pem/pem_lib.c:648:Expecting: ANY PRIVATE KEY
Which I suspect means there is no private key found.
Anyone know what is the issue here? Is this a Heroku issue or an openssl issue (or a DNSimple issue)?
I just struggled mightily with a nearly identical problem installing SSL Certs on a Heroku app with DNSimple and RapidSSL, and want to post my solution here in case someone with a similar problem comes across this response.
I had followed the directions from everywhere on SO and Heroku dev center to install certs through DNSimple and RapidSSL, but every time I tried to add the certs with the command:
$ heroku certs:add server.crt bundle.pem server.key
no matter what I did, I got this error:
$ Adding SSL Endpoint to mysite... failed
! Key could not be read since it's protected by a passphrase.
! Read instructions on how to remove the passphrase on:
! http://www.madboa.com/geek/openssl/#key-removepass`
I knew the key didn't have a passphrase (because I went through that process multiple times) but it still didn't want to add them. I did two things that ultimately got it working though I'm not sure which one was the clincher.
First, I made sure to download the proper PEM file under the Apache, Plesk & CPA box from the RapidSSL email link to Intermediate certificates.
The second thing was to verify my Heroku toolbelt installation by going through the steps here: https://devcenter.heroku.com/articles/heroku-command#installing-the-heroku-cli
Turns out I was still using the gem and had to uninstall until I got to heroku-toolbelt, after which I tried adding the certs again and voila.
Struggled with this issue for days! Until I came across this thread and followed the upgrade advice. The first thing I had to do is
gem uninstall heroku --all
I answered 'Yes' to the keep executable question, because of another post I had read on stackoverflow. I then went to https://toolbelt.herokuapp.com/ and installed the toolbelt (even though heroku --version was saying that it was installed). Upgraded it to heroku-toolbelt 2.39.0. Retried the following command and it worked:
heroku certs:add cert.cer bundle.pem server.key
Maybe i'll finally get some sleep tonight :)
This is really stupid, but as far as I can tell there was an issue with using TextEdit in Mac OS to save the initial server.key and server.orig.crt files.
I used TextMate instead and everything is working fine.
An old toolbelt installation was my problem on windows.
Even though heroku update changed the version number from 2.30.1 to 2.39.0, a heroku version showed it wasn't updating correctly for some reason.
I reinstalled the toolbelt from https://toolbelt.herokuapp.com/ and tried it again, and everything worked.
heroku version now says this for me, and the certs:add works correctly:
heroku-gem/2.39.0 (i386-mingw32) ruby/1.9.2
I now got the same error, even with a recent heroku/7.47.6 (from npm).
The reason turned out to be that I got an elliptic-curve certificate from Let's Encrypt, the private key file contained:
-----BEGIN EC PRIVATE KEY-----
That's not supported according to https://devcenter.heroku.com/articles/acquiring-an-ssl-certificate:
Heroku only supports RSA keys for certs. Elliptic curve keys are not supported.
Once I obtained an RSA cert, it worked.
(specifically, dehydrated now defaults to --algo secp384r1, I had to provide --algo rsa. But the idea should be same with other tools/CAs, you need an RSA cert.)
To me the issue was that 1Password changed newlines in the certificates into spaces, and replacing spaces back into newlines helped (in the cert body, of course, not in the ----BEGIN CERTIFICATE---- part).
So check your cert/key contents, this may be very well an issue of formatting.