SSL Providers - Let's encrypt doesn't seem to work for 'secure your WordPress site'

[skygunner]

When enabled with option wordpressssl: True either with or without this line: wordpressssl_provider: 'letsencrypt'

The result always seems to be self-signed certificate instead of Let's encrypt issued one. Thus Chrome/Firefox will report the site's connection is not secure

using v0.4.0 Ubuntu 16.04.3 LTS

[carlalexander]

Can you go look in /etc/pki/realms/{your_domain}/acme/error.log and post the content here?

[jbeales]

I'm having the same problem, with the same OS/Version.

For me, /etc/pki/realms/{your_domain}/acme/error.log doesn't exist.

[carlalexander]

Can you give post the configuration file that you're using for your server @jbeales?

[jbeales]

inventory/hosts:

# This is an Ansible inventory file in INI format. You can define a list of
# hosts and groups to be managed by this particular inventory.

# Hosts listed under [debops_all_hosts] will have common DebOps plays
# ran against them. It will include services such as iptables, DNS, Postfix,
# sshd configuration and more.
#
# View the list here:
# https://github.com/debops/debops-playbooks/blob/master/playbooks/common.yml

[debops_all_hosts]
ifollowfredericksburg.com

[wordpress]
ifollowfredericksburg.com

host_vars/ifollowfredericksburg.com/vars.yml:

# Make the "Purge Varnish" button work
wordpress__varnish__add_ban_lurker_headers: True
wordpress__varnish__purge_conditions:
  'req.http.X-Purge-Method ~ "(?i)regex"': |
    ban("obj.http.X-Url ~ " + req.url + " && obj.http.X-Host == " + req.http.host);
    return (synth(200, "Purged"));

# Enable SSL, (default provider is LetsEncrypt).
wordpress__ssl: True

# Default Plugins:
wordpress_plugins:
  - name: 'elasticpress'
  - name: 'varnish-http-purge'
  - name: 'redis-cache'

# Only use the key that we want.
wordpress__users__account_ssh_keys: [ '~/path/to/the/one/key/i/want/to/use.pem' ]

# Don't redirect from www -> non-www, (we actually want ot use www)
wordpress__nginx__redirect_from: []

I'm currently running the latest master branch. I had been running the v0.4 tag, but there was a comment on another thread about how something had been fixed since the v0.4 release, so I switched to master.

This happens in both, though.

This is running on EC2, if it matters.

I had to create the pki-acme user manually, as mentioned in another thread. Also, (and I don't have the output for this), it seemed like it was skipping some steps, like uploading to the Lets Encrypt API, and signing certificates, when I ran debops wordpress. I'm not sure if it skipped things on the first run, or just on subsequent runs.

[carlalexander]

I don't officially support AWS yet so it's possible there are issues because of it. You can look at #92 for details. It's pretty much my next priority item.

[mkell43]

I'm having the same issue. The contents of my /etc/pki/realms/mydomain.com/acme/error.log file are below. I replaced my actual domain name with mydomain.com. Another difference is I'm using a DigitalOcean vm and not an AWS instance.

root@wp:~# cat /etc/pki/realms/mydomain.com/acme/error.log
Parsing account key...
Parsing CSR...
Found domains: www.mydomain.com, mydomain.com
Getting directory...
Directory found!
Registering account...
Registered!
Creating new order...
Order created!
Verifying mydomain.com...
mydomain.com verified!
Verifying www.mydomain.com...
Traceback (most recent call last):
  File "/usr/local/lib/pki/acme-tiny", line 198, in <module>
    main(sys.argv[1:])
  File "/usr/local/lib/pki/acme-tiny", line 194, in main
    signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact)
  File "/usr/local/lib/pki/acme-tiny", line 150, in get_crt
    raise ValueError("Challenge did not pass for {0}: {1}".format(domain, authorization))
ValueError: Challenge did not pass for www.mydomain.com: {u'status': u'invalid', u'challenges': [{u'status': u'invalid', u'validationRecord': [{u'url': u'http://www.mydomain.com/.well-known/acme-challenge/0N4Ae1cqJZf3QtZVW52yM3GXVUjLEJROwnk89fJs55w', u'hostname': u'www.mydomain.com', u'port': u'80'}], u'url': u'https://acme-v02.api.letsencrypt.org/acme/challenge/HlXyy6ccoOF7sIJNuyJ3cbnmAxQiEGhULwkTVpziZxQ/5268140463', u'token': u'0N4Ae1cqJZf3QtZVW52yM3GXVUjLEJROwnk89fJs55w', u'error': {u'status': 400, u'type': u'urn:ietf:params:acme:error:dns', u'detail': u'DNS problem: NXDOMAIN looking up A for www.mydomain.com'}, u'type': u'http-01'}, {u'status': u'invalid', u'url': u'https://acme-v02.api.letsencrypt.org/acme/challenge/HlXyy6ccoOF7sIJNuyJ3cbnmAxQiEGhULwkTVpziZxQ/5268140465', u'token': u'HAJXWp5J9Po4CpSm4LqyTPbmf2VvCFcWnVao9fwvs_E', u'type': u'dns-01'}], u'identifier': {u'type': u'dns', u'value': u'www.mydomain.com'}, u'expires': u'2018-06-30T22:18:53Z'}

Edit: Rereading the error message it appears it was trying to create a cert for www.mydomain.com and I did not have a www record set. Re-running against a fresh instance at DigitalOcean after adding a CNAM fixed the issue.

[carlalexander]

Closing and consolidating all VPS documentation issues to #205