I want to Configure SSL / TLS on Amazon Linux "Using Let's Encrypt with Certbot on Amazon Linux ami / 2018.03-release-notes" as described in the document https://docs.aws.amazon.com/fr_fr/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-ami.htmlthe document but but
when I run the sudo yum-config-manager --enable epel
I have some kind of strange messageenter image description here
enter image description here
I don't know what to do anymore, I failed everywhere without success, I don't know if that's the problem.
I have already successfully configured SSL / TLS on Amazon Linux "Using Let's Encrypt with Certbot on Amazon Linux ami / 2018.03-release-notes" as described in the document https://docs.aws.amazon.com/fr_fr /AWSEC2/latest/UserGuide/SSL-on-amazon-linux-ami.htmldescribed in the document this way and I never got this message.
After I try to install certbot as described on the amazon document I have this error
enter image description here
Please help me.
I have a nodejs/express api on a AWS EC2 server with a ssl certificate that is generated with Let's encrypt every 3 months.
Auto renewal isn't on and we let it exipre before trying to renew but after renewing it we are getting an error saying:
Unable to verify the first certificate
or
UNABLE_TO_VERIFY_LEAF_SIGNATURE
depending on what we are testing with.
We are using Certbot for renewing with the following command (and not $ certbot renew) :
$ sudo certbot certonly --dns-route53 -d *.example.com -d example.com --server https://acme-v02.api.letsencrypt.org/directory
Certificates are generated as expected with an expiration date 3 months from now.
Any ideas on what's going on ? I've tried most of the things I could find on SO and elsewhere but nothing worked.
P.S. Servers and I don't go along very well :/ (I do mobile app dev) so assume that I don't know anything when replying :D
Solution was quite easy, just needed to use the fullchain.pem file (and reboot your server if applicable).
Sidenote:
If someone on your team tells you that they've tested a solution and that it didn't work, don't just blindly trust them but test it yourself if all other possible solutions didn't work...(have lost 1+ day because someone thought they did test with the fullchain.pem (or did it wrongly)
I've been following this tutorial to add SSH Certification to my site. However at the moment this method does not work for the time-being due to a security flaw, so here is the alternate method. I'm trying to implement the alternate code-paste: sudo certbot --authenticator webroot --webroot-path <path to served directory> --installer nginx -d <domain> however am not sure what to put in <path to served directory>.
Is the "path to served directory" the nginx config? Would it look something like this: etc/nginx/sites-available/<projectname>?
You may have tried this already, but I found this to work, at least until an update is issued:
sudo certbot --authenticator standalone --installer nginx -d mydomain.com -d www.mydomain2.com --pre-hook "service nginx stop" --post-hook "service nginx start"
If you are on for debian/ubuntu and running apache this will work for you :
sudo certbot --authenticator standalone --installer apache -d <yourdomain(s)> --pre-hook "apache2ctl stop" --post-hook "apache2ctl start"
Source : Github
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 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