This is my first post here. Recently I have changed my server. Now I am using Debian 11 and can't figure out how to setup certbot to behave like previous version.
Renewal of certs works like a charm. The strange thig was that certbot installed by snapd did not setup auto renewal or at least there was now cron.d, cronatab and also systemctl timres entries. So I put simple crontab: certbot renew >> /var/log/logfile.
On my previous server when it was run I received meesages like that:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Cert not yet due for renewal
and when it was renewed there was also information. Now in the latest version of certbot 1.22.0 I got email only saying that certbot was run: "Saving debug log to /var/log/letsencrypt/letsencrypt.log"
Is there any way to change this to tell that certs are not renewed? And the second question is do I need to restart apache server after such cronjob to install new certs?
How do I setup SSL for DigitalOcean droplet running OpenLiteSpeed NodeJS? Is there any command that I can run to make this possible? Thanks
Auto setup:
An interactive script that runs will first prompt you for your domain or subdomain.
You can press CTRL+C and continue to SSH. The prompt will open again the next time you log in, and will continue to do so until you finish the whole setup.
Please input a valid domain:
Please verify it is correct. [y/N]
Enter the root domain only, then the system will add both the root domain and the www domain for you.
You can also automatically apply Let's Encrypt SSL if your domain is pointed to this server already. Enter y and your email address to finish the process.
Do you wish to issue a Let's encrypt certificate for this domain? [y/N]
Please enter your E-mail:
Please verify it is correct: [y/N]
Once finished, you should see Certificate has been successfully installed...
Do you wish to force the HTTPS rewrite rule for this domain? [y/N]
Once finished, force HTTPS rules will be applied
Do you wish to update the system which includes the webserver? [Y/n]
This script will automatically go away after your domain has been added.
Manually setup:
Navigate to OpenLiteSpeed Web Server WebAdmin > Listeners, and add Your Domain to HTTP/HTTPS.
Once the DNS records are set up, you can generate the SSL certificate. Be sure to substitute the correct domain name in the following command:
certbot certonly --webroot -w /var/www/html/ -d example.com -d www.example.com
Navigate to OpenLiteSpeed Web Server WebAdmin > Listeners > SSL, and edit the following three items:
Private Key File = /etc/letsencrypt/live/example.com/privkey.pem
Certificate File = /etc/letsencrypt/live/example.com/fullchain.pem
Chained Certificate = Yes
Save and perform a Graceful Restart.
Refer https://docs.litespeedtech.com/cloud/images/nodejs/#optional-setup
I have an SSL certificate issued by https://letsencrypt.org/ . It will be expiring tomorrow and I am having trouble renewing it. I have spun up a fresh linux box, installed certbot (as per https://letsencrypt.org/getting-started/ ) . I have the following saved in a local directory:
cert.pem
chain.pem
fullchain.pem
privkey.pem
Within the directory that contains the certificate I then run
/path/to/certbot/certbot-auto renew --dry-run --force-renew
certbot appears to not find the certificates as it then says
No renewals were attempted.
I have also run
/path/to/certbot/certbot-auto renew --force-renew
and get the same response.
Is there a way to renew certificates that are not stored in the expected /letsencrypt/archive/... folder as is the case for a fresh installation on a fresh box?
I have a nodejs app on openshift, and we use the rhc port-forward command to connect to our database when we develop locally.
We have implemented passport to authenticate users through google and through facebook. I have authenticated my self, and we could still use the rhc commands. My partner has recently authenticated himself through facebook, and shortly after that (~1 week), we got this error thrown our way. Dont know if that is entirely relevant, but it couldn't hurt to include.
Connection to openshift.redhat.com failed: A secure connection could not be established to the server
(SSL_connect returned=1 errno=0 state=SSLv3 read server hello A: sslv3 alert handshake failure). You may
disable secure connections to your server with the -k (or --insecure) option
'https://openshift.redhat.com/broker/rest/api'.
If your server is using a self-signed certificate, you may disable certificate checks with the -k (or
--insecure) option. Using this option means that your data is potentially visible to third parties.
Any ideas on how to resolve this? I have seen this error on other stack questions, but every question I saw, the people posing the question were using ruby.
This is likely a result of the POODLE SSLv3 debacle. You can fix it by updating the httpclient ruby gem. At the command line type:
sudo gem update httpclient
Or you can also fix it by adding the following to your .openshift/express.conf file:
ssl_version=tlsv1
Both of these fixes essentially tell your app to use TLSv1 instead of SSLv3.
The rhc gem has been updated, please run gem update rhc and you will get the newest fixed version.
I had the same issue on Windows with ruby 1.9.3 and httpclient 2.3.4.1
gem update httpclient updated the same to 2.5.3.3 and thus fixed the issue.
I am running a server that accepts https requests. I have generated my own certificate. When going to the site in firefox I get the unknown certificate error, but that's fine. This (I think) indicates that port forwarding and such works.
I am trying to use svn with this. When using svn on the server (but using the external ip) it works. Again I get the certificate is unknown, but I don't care.
When using svn on mac OS X I get
SSL negotiation failed: SSL error code -1/1/336032856
I've found several posts on google about this, but they all say it's a bug with openssl version 0.9.8, and that using something higher should fix it.
I am currently using openssl 1.0.0c. I have no idea what's going wrong. I also checked the error log in httpd and nothing comes up.
Any ideas on this would really help.
Thanks
Upgrading from SVN 1.6.15 to 1.6.16 fix this issue for me.
I received the same error message when my Apache configuration was wrong - my ServerName parameter in httpd.conf did not match hostname in the self-signed certificate.
I started getting this error from older subversion clients (Tortoise 1.6.4 i think, and pysvn r1280) when our svn server had its Apache instance upgraded. It went from using OpenSSL 0.9.8n to 1.0.0d.
Tortoise got fixed by upgrading to 1.6.16 (uses OpenSSL 1.0.0d).
Fixing pysvn was a different story. The latest version (r1360) came bac kwith the same error. There didn't seem to be much info around apart from hints that OpenSLL might need upgrading. I tried copying in different versions of OpenSSL (libeay32.dll and ssleay32.dll) and here are the results:
0.9.8j (the existing DLL version, bundled with pysvn r1280) FAIL
0.9.8o (bundled with the latest pysvn, r1360) FAIL
0.9.8r (the latest in the 0.9.8 series) FAIL
1.0.0* (the 1.0 series is not binary compatible with pysvn) FAIL
0.9.8L (nabbed from CollabNet SVN 1.6.9 command line client) SUCCESS!
So whatever they fixed in release L got broken again soon after, or there's something special about CollabNet's OpenSSL binaries.
In my case it started happening after some certificates changes on the server side. I tried deleting the .subversion/ dir, updating openssl, openssh, svn, and nothing...
It got finally fixed when I replaced the url host name with the ip address of that host.
In existing working copies was enough with:
svn switch --relocate http://hostname.com https://ipaddress
Not sure if this is a bug or what, but it seems that the new certificates are not recognized and keeps using the old cached ones for a given host name.
I agree with the earlier answer by Lukas Cenovsky, that setting ServerName in the apache configuration fixes the problem.
In this link http://www.elegosoft.com/files/svn-day-berlin-2011_sperling_subversion-error-messages-demystified.pdf it is said that the error originates from the SSL library.
The full error message(just to enable better google indexing) I receive is:
$ svn ls https://www.OMITTED.dk/svn
svn: E175002: Unable to connect to a repository at URL 'https://www.OMITTED.dk/svn'
svn: E175002: OPTIONS of 'https://www.OMITTED.dk/svn': SSL handshake failed: SSL error code -1/1/336032856 (https://www.OMITTED.dk)
In the file /etc/apache2/sites-available/ssl (debian linux)
I added the ServerName as:
NameVirtualHost *:443
<VirtualHost *:443>
ServerAdmin webmaster#localhost
SSLEngine On
ServerName www.OMITTED.dk
See what happens if you eliminate the SSL problem by adding your generated certificate to your client's trusted certificate store.
One step ahead, my case is a MSWindows Client workstation and a CentOs server with Apache.
Using Tortoise Subversion 1.6.16, I realise that after execute a "svn checkout https://OMITTED.dk/project", I got the same ssl handshake error.
What I did was
update c:\windows\system32\drivers\etc\hosts with "IP_address
OMITTED.dk"
update the entries with the project directory. Edit the
file project/entries and replace the IP_address by OMITTED.dk.
Thus I try the command : svn update path_to_project --non-interactive --trust-server-cert.
Hope will be usefull