search

Varying-Vagrant-Vagrants / VVV

An open source Vagrant configuration for developing with WordPress
https://varyingvagrantvagrants.org
MIT License
4.54k stars 848 forks source link

SSL not working on wp sites #2107

Closed Lepelaar closed 4 years ago

Lepelaar commented 4 years ago

What was The Command Used To Provision

vagrant up --provision

What Kind of VVV Provision Was This

This was a reprovision of an already working VVV

Logs/What Broke

After importing the CA certificate in my browser (FF 75.0 64-bits) , the SSL on the dashboard (https://vvv.test) worked fine, but the 3 sites I provisioned all refused to accept an SSL connection. This was on my home computer, using the scripts I copied from work that were running fine there.

In the config.yml there are 3 sites (using https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git), one with 3 different hostnames and two with just 1 host; none of the hosts are working with SSL. This config.yml was working fine at work. All the certificates are in the right place (for each site) and the openssl.conf-files in those directories have [alt_names] with the proper hostnames.

I checked all the logs and only found one small error caused by my own php script in the first site that prevented WP from starting up. After fixing that, I deleted the ca.crt from the browser and did a new provisioning. The script error was no longer there, but the situation was the same: vvv.test was fine (after importing the new ca.crt) but none of the sites worked with https.

Finally I used vagrant SSH to check nginx on the server and found the symlinks for the certificates in place as well.

Possible Solution

I have no clue what could be wrong, neither what to try next.... :-(

Steps to Reproduce (for bugs)

--

Your Environment

Operating System: Windows10 (Home V1903) platform-mingw32 windows HasWinAdminPriv vagrant-hostsupdater NoColour shared_db_folder_disabled , VVV Path: "C:/vagrant-solid" Vagrant: v2.2.6

tomjn commented 4 years ago

hmmm, do you have a custom nginx config? What does your custom script do? And what does Firefox say about the SSL certificate it's being served? Is it for the correct domain? Or is it the default VVV certificate?

My suspicion, is that the SSL certificate is fine, but the Nginx config hasn't been told to serve it

Lepelaar commented 4 years ago

No custom nginx config, just the default stuff from the vvv package. My script is just a simple plugin-like php file, that caused WP to break.

 * Running provisioner for site wps1

! Site provisioner failed! Check the full log for more details

---------------------------------------------

I just removed the faulty script and the WP site came up as expected. After this I did the second provisioning and no longer got errors of any kind. But no SSL :-(

When I try https://hostname.test FF shows the (yellow bordered) "Warning: security risk"

Error code: SSL_ERROR_BAD_CERT_DOMAIN

The certificate info in FF: VVV INTERNAL CA vvv,test

the about:certificate page only mentions vvv.test as DNS (and some variations like *.vvv.test, vvv, vvv.local etc. ) None of the hostnames are mentioned in this page.

Lepelaar commented 4 years ago

Also, at first 

Reloading Nginx
nginx.service is not active, cannot reload.

was in the error logs for site wps2 and wps3 as well. But after the second provisioning this no longer happened; all finished:

[38;5;2m * Site provisioner script finished successfully

tomjn commented 4 years ago

Theory 1:

Keep in mind that the site provisioner will fail when any of the commands it runs fails.

This means if it tries to run WP CLI commands, and it fails or returns an error code, bash exits the script, the site provisioner declares it a failure, and the error message gets shown.

Since nginx configs are the very last thing that happens in the site config, no nginx configuration would get installed for that site.

Case in point I would expect s-trade.test not to load over http://, or if it did, you'd get the main dashboard.

Theory 2:

Perhaps you didn't trust the root certificate, but the default certificate instead? That would allow the main vvv.test dashboard to work over HTTPS but would mean every other site had an unknown issuer.

Here's what one.wordpress.test shows for me in firefox:

Screenshot 2020-04-08 at 22 34 37

Note the common name, the root CA doesn't have that common name, at least not in the same place

And I imported the certificate in certificates/ca/ca.crt

Here's what that looks like for me:

Screenshot 2020-04-08 at 22 40 32 Screenshot 2020-04-08 at 22 40 39
Lepelaar commented 4 years ago

Based on your information I checked again:

Theory 1: all the sites work fine over http:// also I checked all the logs again and found no errors (the "worst" thing I found were warnings about the all plugins already installed and activated)

Theory 2: I did install the right ca.crt (the one in certificates/ca/ca.crt ) later I did try other certs from the other dirs but they would not load in FF; and BTW there is only one ca.crt; all the others are dev.crt My FF only shows the first situation (vvv.test) but none for one of the hosts (like one.wordpress.test)

If I load https://s-trade.test in FF and click the lock icon (with a warning triangle in it) and go to the certificate info, it shows ONLY vvv.test in the çommon name or DNS-name fields NO s-trade.test or any other. I get the feeling there is something wrong with my FF

So theory 2 seems the most likely scenario, but I don't know what's going wrong.

tomjn commented 4 years ago

Do the sites work ok over https in Chrome/Edge? If you go into the VM and check /etc/nginx/custom-sites does the nginx config for those sites refer to the correct TLS files for the certificate and the key?

Here's what my one.wordpress.test looks like:

vvv-auto-wordpress-one-provision-60730e707ede8a21f013860b6fc556e1.conf:

server {
    listen       80;
    listen       443 ssl http2;
    server_name  one.wordpress.test;
    root         /srv/www/wordpress-one/public_html;

    # Nginx logs
    error_log    /srv/www/wordpress-one/log/nginx-error.log;
    access_log   /srv/www/wordpress-one/log/nginx-access.log;

    # This is needed to set the PHP being used
    set          $upstream php;

    # Enable server push if SSL/HTTP2 is being used for link preload headers
    http2_push_preload on;

    ssl_certificate /srv/certificates/wordpress-one/dev.crt;
    ssl_certificate_key /srv/certificates/wordpress-one/dev.key;

    # Nginx rules for WordPress, rewrite rules, permalinks, etc
    include      /etc/nginx/nginx-wp-common.conf;

}
Lepelaar commented 4 years ago

In chrome https://vvv.test works; others only work over http://

Here is my config of wps1; ssl_certificates and ssl_certificates_key are missing (there is even literally a gap there).

Can I edit this manually via ssh? or should I change stuff in vvv and re-provision?

server {
    listen       80;
    listen       443 ssl http2;
    server_name  s-trade.test pws.test k1.pws.test k2.pws.test bws.test;
    root         /srv/www/wps1/public_html;

    # Nginx logs
    error_log    /srv/www/wps1/log/nginx-error.log;
    access_log   /srv/www/wps1/log/nginx-access.log;

    # This is needed to set the PHP being used
    set          $upstream php;

    # Enable server push if SSL/HTTP2 is being used for link preload headers
    http2_push_preload on;

    # Nginx rules for WordPress, rewrite rules, permalinks, etc
    include      /etc/nginx/nginx-wp-common.conf;

}
tomjn commented 4 years ago

That entire folder is wiped clean on every provision. Are you absolutely sure you're not using a custom provisioner script? Or that it's up to date?

That section of the nginx config will be blank if /srv/config/homebin/is_utility_installed core tls-ca says no:

  if /srv/config/homebin/is_utility_installed core tls-ca; then
    sed -i "s#{vvv_tls_cert}#ssl_certificate /srv/certificates/${VVV_SITE_NAME}/dev.crt;#" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
    sed -i "s#{vvv_tls_key}#ssl_certificate_key /srv/certificates/${VVV_SITE_NAME}/dev.key;#" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
  else
    sed -i "s#{vvv_tls_cert}##" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
    sed -i "s#{vvv_tls_key}##" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
  fi

If you run:

/srv/config/homebin/is_utility_installed core tls-ca
echo $?

What does it say? And can you confirm you have the tls-ca utility in your config/config.yml?

tomjn commented 4 years ago

I've updated the site provisioner on the develop branch to leave a comment rather than blank if the TLS-CA utility is not active

Lepelaar commented 4 years ago

Positive about not using a custom provisioner script. I did this install of VVV on 03-16-2020. No modifications from the default install, only thing I changed was the the config.yml (replaced with the one I got from work; also I added a few PHP files in wp-content/mu-plugins after the first provisioning)

This config.yml file has the tls-ca in utilties: core: section

running '/srv/config/homebin/is_utility_installed core tls-ca' did not return anything

I did however find that part in provision/provision-site.sh :

if [[ $(/srv/config/homebin/is_utility_installed core tls-ca) ]]; then
    sed -i "s#{vvv_tls_cert}#ssl_certificate /srv/certificates/${VVV_SITE_NAME}/dev.crt;#" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
    sed -i "s#{vvv_tls_key}#ssl_certificate_key /srv/certificates/${VVV_SITE_NAME}/dev.key;#" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
  else
    sed -i "s#{vvv_tls_cert}##" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
    sed -i "s#{vvv_tls_key}##" "/etc/nginx/custom-sites/${DEST_NGINX_FILE}"
  fi

And thank you SO MUCH for trying to help me out with this!!

tomjn commented 4 years ago

@Lepelaar can you switch to the develop branch? And can you show me your utilities section exactly as it is in your config file in a code block? As well as the output from the command I mentioned? It looks like you forgot to run echo $? to see what the return code was, is_utility_installed has no output to the terminal, only a return code of 1 or 0.

Also on the develop branch, is the TLS section still blank? Or does it have those comments I added?

Lepelaar commented 4 years ago

How do I switch to the develop branch? Should I use git clone -b develop git://github.com/Varying-Vagrant-Vagrants/VVV.git ? Will I loose data that's already there?

tomjn commented 4 years ago

I thought you were on develop and switched to master? git checkout develop, git pull and vagrant up --provision should be enough, git clone is for taking what's in a git repo, and setting up a brand new folder

Lepelaar commented 4 years ago

Ah yes, of course (don't use git very often...)

This is what happened:

PS C:\vagrant-solid> git checkout develop
Already on 'develop'
Your branch is up to date with 'origin/develop'.
PS C:\vagrant-solid> git pull
Already up to date.
PS C:\vagrant-solid> vagrant up

At first it looked like provisioning went smooth, but then it ended with "Provisioning incomplete"

\ V\ V\ V / Varying Vagrant Vagrants
 \_/\_/\_/  v3.3.0-git::develop

Platform: platform-mingw32 windows  HasWinAdminPriv  vagrant-hostsupdater  NoColour shared_db_folder_disabled, VVV Path: "C:/vagrant-solid"
Vagrant: v2.2.6, VirtualBox: v6.0.12r133076

Docs:       https://varyingvagrantvagrants.org/
Contribute: https://github.com/varying-vagrant-vagrants/vvv
Dashboard:  http://vvv.test

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'ubuntu/bionic64' version '20191018.0.0' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection reset. Retrying...
    default: Warning: Connection aborted. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: prevent things such as shared folders from working properly. If you see
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 5.2.8_KernelUbuntu r120774
    default: VirtualBox Version: 6.0
==> default: [vagrant-hostsupdater] Checking for host entries
==> default: [vagrant-hostsupdater]   found entry for: 192.168.50.4 vvv
==> default: [vagrant-hostsupdater]   found entry for: 192.168.50.4 vvv.test
==> default: [vagrant-hostsupdater] Writing the following entries to (C:/WINDOWS/system32/drivers/etc/hosts)
==> default: [vagrant-hostsupdater]   192.168.50.4  s-trade.test  # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6
==> default: [vagrant-hostsupdater]   192.168.50.4  pws.test  # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6
==> default: [vagrant-hostsupdater]   192.168.50.4  k1.pws.test  # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6
==> default: [vagrant-hostsupdater]   192.168.50.4  k2.pws.test  # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6
==> default: [vagrant-hostsupdater]   192.168.50.4  bws.test  # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6
==> default: [vagrant-hostsupdater]   192.168.50.4  shopical.test  # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6
==> default: [vagrant-hostsupdater]   192.168.50.4  shoppingcart.test  # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6
==> default: [vagrant-hostsupdater] This operation requires administrative access. You may skip it by manually adding equivalent entries to the hosts file.
==> default: Setting hostname...
==> default: Configuring and enabling network interfaces...
==> default: Mounting shared folders...
    default: /srv/www => C:/vagrant-solid/www
    default: /srv/config => C:/vagrant-solid/config
    default: /var/log/php => C:/vagrant-solid/log/php
    default: /srv/database => C:/vagrant-solid/database/sql
    default: /var/log/nginx => C:/vagrant-solid/log/nginx
    default: /srv/provision => C:/vagrant-solid/provision
    default: /srv/certificates => C:/vagrant-solid/certificates
    default: /var/log/memcached => C:/vagrant-solid/log/memcached
    default: /var/log/provisioners => C:/vagrant-solid/log/provisioners
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.
==> default: Running action triggers after up ...
==> default: Running trigger: VVV Post-Up...
    default: Running: inline script
    default:  * Restarting Nginx and MySQL
    default:
    default:      oh noes :'(
    default:    ▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄                 __ __ __ __
    default:    █▒▒░░░░░░░░░▒▒█    Provisioning \ V\ V\ V /
    default:     █░░█░░░░░█░░█     incomplete!   \_/\_/\_/
    default:      █░░░▀█▀░░░█
    default:    ▄▄▀▄░░░░░░░▄▀▄▄    Check the logs and reprovision.
    default:                       If that fails, go to the VVV Slack or open an issue
    default:                       on GitHub. Logs are in the logs/provisioners folder.
    default:

But the sites are working nevertheless. ( https://vvv.test/ other sites only http://... ) On first inspection did not find anything suspicious in the logs either.

Running

/srv/config/homebin/is_utility_installed core tls-ca
echo $?

returned 0 this time, but just before I did the git stuff and provisioning it returned 1 !

It gets even stranger: ssl_cert's now are showing up ( vvv-auto-wps1-provision-2b5cb5d5a3b53bc41a8727a72be464b1.conf )

server {
    listen       80;
    listen       443 ssl http2;
    server_name  s-trade.test pws.test k1.pws.test k2.pws.test bws.test;
    root         /srv/www/wps1/public_html;

    # Nginx logs
    error_log    /srv/www/wps1/log/nginx-error.log;
    access_log   /srv/www/wps1/log/nginx-access.log;

    # This is needed to set the PHP being used
    set          $upstream php;

    # Enable server push if SSL/HTTP2 is being used for link preload headers
    http2_push_preload on;

    ssl_certificate /srv/certificates/wps1/dev.crt;
    ssl_certificate_key /srv/certificates/wps1/dev.key;

    # Nginx rules for WordPress, rewrite rules, permalinks, etc
    include      /etc/nginx/nginx-wp-common.conf;

}

Also checked this for wps2 and wps3

And here is a copy of that block from config.yml

utilities:
  core: # The core VVV utility
    - tls-ca # HTTPS SSL/TLS certificates
    - phpmyadmin # Web based database client
    #- memcached-admin # Object cache management
    #- opcache-status # opcache management
    #- webgrind # PHP Debugging
    #- mongodb # needed for Tideways/XHGui
    #- tideways # PHP profiling tool, also installs xhgui check https://varyingvagrantvagrants.org/docs/en-US/references/tideways-xhgui/
    #- php56
    #- php70
    #- php71
    #- php72
    #- php73
    #- php74

For completeness I attached a zip with the provisioning logs

2020.04.09_13-49-35.zip

tomjn commented 4 years ago

So now that the certificates are in the nginx config, what does the browser say is wrong with the certificate? What kind of broken is it giving you? Unknown issues? Bad common name?

Ignore the sad bear for now, I think the check that switches the bears is broken

On Thu, 9 Apr 2020 at 16:02, Lepelaar notifications@github.com wrote:

Ah yes, of course (don't use git very often...)

This is what happened:

PS C:\vagrant-solid> git checkout develop

Already on 'develop'

Your branch is up to date with 'origin/develop'.

PS C:\vagrant-solid> git pull

Already up to date.

PS C:\vagrant-solid> vagrant up

At first it looked like provisioning went smooth, but then it ended with "Provisioning incomplete"

\ V\ V\ V / Varying Vagrant Vagrants

_/_/_/ v3.3.0-git::develop

Platform: platform-mingw32 windows HasWinAdminPriv vagrant-hostsupdater NoColour shared_db_folder_disabled, VVV Path: "C:/vagrant-solid"

Vagrant: v2.2.6, VirtualBox: v6.0.12r133076

Docs: https://varyingvagrantvagrants.org/

Contribute: https://github.com/varying-vagrant-vagrants/vvv

Dashboard: http://vvv.test

Bringing machine 'default' up with 'virtualbox' provider...

==> default: Checking if box 'ubuntu/bionic64' version '20191018.0.0' is up to date...

==> default: Clearing any previously set forwarded ports...

==> default: Clearing any previously set network interfaces...

==> default: Preparing network interfaces based on configuration...

default: Adapter 1: nat

default: Adapter 2: hostonly

==> default: Forwarding ports...

default: 22 (guest) => 2222 (host) (adapter 1)

==> default: Running 'pre-boot' VM customizations...

==> default: Booting VM...

==> default: Waiting for machine to boot. This may take a few minutes...

default: SSH address: 127.0.0.1:2222

default: SSH username: vagrant

default: SSH auth method: private key

default: Warning: Connection reset. Retrying...

default: Warning: Connection aborted. Retrying...

==> default: Machine booted and ready!

==> default: Checking for guest additions in VM...

default: The guest additions on this VM do not match the installed version of

default: VirtualBox! In most cases this is fine, but in rare cases it can

default: prevent things such as shared folders from working properly. If you see

default: shared folder errors, please make sure the guest additions within the

default: virtual machine match the version of VirtualBox you have installed on

default: your host and reload your VM.

default:

default: Guest Additions Version: 5.2.8_KernelUbuntu r120774

default: VirtualBox Version: 6.0

==> default: [vagrant-hostsupdater] Checking for host entries

==> default: [vagrant-hostsupdater] found entry for: 192.168.50.4 vvv

==> default: [vagrant-hostsupdater] found entry for: 192.168.50.4 vvv.test

==> default: [vagrant-hostsupdater] Writing the following entries to (C:/WINDOWS/system32/drivers/etc/hosts)

==> default: [vagrant-hostsupdater] 192.168.50.4 s-trade.test # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6

==> default: [vagrant-hostsupdater] 192.168.50.4 pws.test # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6

==> default: [vagrant-hostsupdater] 192.168.50.4 k1.pws.test # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6

==> default: [vagrant-hostsupdater] 192.168.50.4 k2.pws.test # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6

==> default: [vagrant-hostsupdater] 192.168.50.4 bws.test # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6

==> default: [vagrant-hostsupdater] 192.168.50.4 shopical.test # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6

==> default: [vagrant-hostsupdater] 192.168.50.4 shoppingcart.test # VAGRANT: 128a37bb70baaedb2aaef207bd3eb9ee (default) / 7640222d-04e7-4141-bd51-669d2e5393a6

==> default: [vagrant-hostsupdater] This operation requires administrative access. You may skip it by manually adding equivalent entries to the hosts file.

==> default: Setting hostname...

==> default: Configuring and enabling network interfaces...

==> default: Mounting shared folders...

default: /srv/www => C:/vagrant-solid/www

default: /srv/config => C:/vagrant-solid/config

default: /var/log/php => C:/vagrant-solid/log/php

default: /srv/database => C:/vagrant-solid/database/sql

default: /var/log/nginx => C:/vagrant-solid/log/nginx

default: /srv/provision => C:/vagrant-solid/provision

default: /srv/certificates => C:/vagrant-solid/certificates

default: /var/log/memcached => C:/vagrant-solid/log/memcached

default: /var/log/provisioners => C:/vagrant-solid/log/provisioners

==> default: Machine already provisioned. Run vagrant provision or use the --provision

==> default: flag to force provisioning. Provisioners marked to run always will still run.

==> default: Running action triggers after up ...

==> default: Running trigger: VVV Post-Up...

default: Running: inline script

default:  * Restarting Nginx and MySQL

default:

default:      oh noes :'(

default:    ▄▀▀▀▄▄▄▄▄▄▄▀▀▀▄                 __ __ __ __

default:    █▒▒░░░░░░░░░▒▒█    Provisioning \ V\ V\ V /

default:     █░░█░░░░░█░░█     incomplete!   \_/\_/\_/

default:      █░░░▀█▀░░░█

default:    ▄▄▀▄░░░░░░░▄▀▄▄    Check the logs and reprovision.

default:                       If that fails, go to the VVV Slack or open an issue

default:                       on GitHub. Logs are in the logs/provisioners folder.

default:

But the sites are working nevertheless. ( https://vvv.test/ other sites only http://... ) On first inspection did not find anything suspicious in the logs either.

Running

/srv/config/homebin/is_utility_installed core tls-ca

echo $?

returned 0 this time, but just before I did the git stuff and provisioning it returned 1 !

It gets even stranger: ssl_cert's now are showing up ( vvv-auto-wps1-provision-2b5cb5d5a3b53bc41a8727a72be464b1.conf )

server {

listen       80;

listen       443 ssl http2;

server_name  s-trade.test pws.test k1.pws.test k2.pws.test bws.test;

root         /srv/www/wps1/public_html;

# Nginx logs

error_log    /srv/www/wps1/log/nginx-error.log;

access_log   /srv/www/wps1/log/nginx-access.log;

# This is needed to set the PHP being used

set          $upstream php;

# Enable server push if SSL/HTTP2 is being used for link preload headers

http2_push_preload on;

ssl_certificate /srv/certificates/wps1/dev.crt;

ssl_certificate_key /srv/certificates/wps1/dev.key;

# Nginx rules for WordPress, rewrite rules, permalinks, etc

include      /etc/nginx/nginx-wp-common.conf;

}

Also checked this for wps2 and wps3

And here is a copy of that block from config.yml

utilities:

core: # The core VVV utility

- tls-ca # HTTPS SSL/TLS certificates

- phpmyadmin # Web based database client

#- memcached-admin # Object cache management

#- opcache-status # opcache management

#- webgrind # PHP Debugging

#- mongodb # needed for Tideways/XHGui

#- tideways # PHP profiling tool, also installs xhgui check https://varyingvagrantvagrants.org/docs/en-US/references/tideways-xhgui/

#- php56

#- php70

#- php71

#- php72

#- php73

#- php74

For completeness I attached a zip with the provisioning logs

2020.04.09_13-49-35.zip https://github.com/Varying-Vagrant-Vagrants/VVV/files/4456914/2020.04.09_13-49-35.zip

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Varying-Vagrant-Vagrants/VVV/issues/2107#issuecomment-611576918, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOLZ4XFR62MOEYAKQP54TRLXPQTANCNFSM4MEGEY7Q .

Lepelaar commented 4 years ago

Yeah LOL, that Sad Bear got me :-)) I restarted VVV and my browser and.... all is working fine now!

Thank you so very much, Tom!!

But why did I see: Your branch is up to date with 'origin/develop'. I thought nothing had changed.

Anyways I am on track now. Thanks again!

lock[bot] commented 4 years ago

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.