I’ve managed to get a working client install on one CentOS6.7 server, but cannot replicate it again (not even on the same server under new account). This leads me to think the problem is in the virtual environment rather than server environment. Is it safe to just copy an installation to another account or another server running same OS (ie to get this to my production account I would copy entire home dir)
And there was a recent OpenSSL update on CentOS, but openssl-1.0.1e-42.el6_7.4.x86_64 was installed on March 2, working lets encrypt installed on Mar 14.
As a new user I can neither attach log file nor past full log. This is what is at the very end:
File “/home/securemail/.local/share/letsencrypt/lib/python2.7/site-packages/pip/basecommand.py”, line 169, in main
text = ‘\n’.join(complete_log)
UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe2 in position 36: ordinal not in range(128)
I have made progress to where I can consistently install the client on the one server where it first worked.
I also have made some progress on the second server where the client has never installed and probably tracked that down to wrong version of libffi. Error now I’m stuck at is
c/_cffi_backend.c:13:17: error: ffi.h: No such file or directory
So that’s on me to sort out. I don’t know if we can downgrade without breaking other things (this a mail server with the SOGo groupware that provides the Exchange ActiveSync features and there are some other options for providing that I am looking at).
Thanks also for pointing me back to the top of the error stack. I’ve beat on this for a couple days and was close on this once before. I now realize I had been inconsistent in invoking the right python, thinking that the ‘scl python27 bash’ command was a one-time step. And now I understand why I had to logout twice
P.S. Paradox here is that I am installing Let’s Encrypt in part because Outlook doesn’t like self-signed certificates, and I haven’t been able to properly test out SOGo to be sure it is what we need. For that purpose I can probably downgrade, get the certs and then restore.
Thank you. I made it work once (the story of my life right now). Except I forgot the importance of adding the autodiscover A record to the certificate. All subsequent attempts to create new certs fail. Clearly the problem is on my end. I’m about to nuke this install and start from scratch. I can’t even clone any more, and the error is also local SSL for some reason. Fresh user checkout and no love.
$ git clone https://github.com/Neilpang/le.git
Initialized empty Git repository in /home/securemail/le/.git/
error: while accessing https://github.com/Neilpang/le.git/info/refs
fatal: HTTP request failed
I can make that work by doing
git config --global http.sslverify false
Which probably isn’t a good idea.
And on my test box, where I don’t need it, git clone works fine.
Edit: yeah, don’t mess with /etc/pki/tls/certs/ca-bundle.crt. It screws up yum too.
