37

On my Ubuntu 16.04 server, I have an Apache conf file at /etc/apache2/sites-enabled/000-default.conf, which looks like this (abbreviated):

WSGIApplicationGroup %{GLOBAL}

<VirtualHost *:80>
    ServerName example.com
    WSGIDaemonProcess myprocess user=ubuntu group=ubuntu threads=10 home=/home/ubuntu/myapp
    WSGIProcessGroup myprocess
    ...
</VirtualHost>

It works fine in HTTP mode, but when I run $ sudo certbot --apache to set up HTTPS, it fails with the error Syntax error on line 7 of /etc/apache2/sites-enabled/000-default.conf: Name duplicates previous WSGI daemon definition. Line 7 is the line beginning with WSGIDaemonProcess.

Josh
  • 2,790
  • 26
  • 30

3 Answers3

52

It turns out that if my Apache conf file 000-default.conf only declares <VirtualHost *:80>...</VirtualHost>, then Certbot duplicates it and creates a second Apache conf file called 000-default-le-ssl.conf to define <VirtualHost *:443>...</VirtualHost>.

The Name duplicates previous WSGI daemon definition error appears because both Apache conf files have the same line defining WSGIDaemonProcess myprocess.... This appears to be a known Certbot bug.

The workaround I've found is to define both VirtualHosts (80 and 443) in the same Apache conf file (so that Certbot doesn't create a second file), and to define WSGIDaemonProcess outside both VirtualHosts, like this:

WSGIApplicationGroup %{GLOBAL}
WSGIDaemonProcess myprocess user=ubuntu group=ubuntu threads=10 home=/home/ubuntu/myapp
WSGIProcessGroup myprocess

<VirtualHost *:80>
    ServerName example.com
    ...
</VirtualHost>
<VirtualHost *:443>
    ServerName example.com
    ...
</VirtualHost>
Josh
  • 2,790
  • 26
  • 30
  • 2
    certbot actually procures the certificate but fails in configuring for the reason you mentioned. I added the configuration manually in httpd-le-ssl.conf and ran certbot again (just in case) and it worked fine. – iceman May 17 '18 at 08:03
  • This does not work. @lxmmxl56 solution is the only one that works – Bogdan Mar 08 '20 at 06:02
18

As the error says, you cannot use the same name for a WSGIDaemonProcess definition more than once. They have to be unique for the whole Apache instance.

If you have both 80 and 443 instances of the VirtualHost for same ServerName, you shouldn't create a separate WSGIDaemonProcess in the 443 instance. Define it in the 80 instance and reference by name from the 443 instance. That way you share the same daemon process group between 80 and 443 instances of the VirtualHost for the same ServerName.

WSGIApplicationGroup %{GLOBAL}
WSGIRestrictEmbedded On

<VirtualHost *:80>
ServerName example.com
WSGIDaemonProcess myprocess threads=10 home=/home/ubuntu/myapp
WSGIProcessGroup myprocess
...
</VirtualHost>

<VirtualHost *:443>
ServerName example.com
WSGIProcessGroup myprocess
...
</VirtualHost>
Graham Dumpleton
  • 57,726
  • 6
  • 119
  • 134
  • 2
    My main problem is how to get Certbot to run as automatically as possible. To that end, is it OK to define `WSGIDaemonProcess` outside of ``? P.S. It's pretty cool to get my question answered by the architect of `mod_wsgi` himself! – Josh Dec 13 '17 at 22:54
  • 3
    Yes, you can put the ``WSGIDaemonProcess`` directive outside of the ``VirtualHost``. – Graham Dumpleton Dec 13 '17 at 23:22
  • 1
    this should be the answer :) – vee Jan 27 '19 at 19:07
  • Putting WSGIDaemonProcess outside virtual host will probably cause issues if you have multiple websites being served on the same server since it wn't be associated with a particular website. – user984003 Oct 19 '20 at 20:22
  • 1
    Since you must have the `WSGIProcessGroup` directive, or `process-group` option to `WSGIScriptAlias` to say which daemon process group to use, having it outside is not an issue. In other words, you have to say which to use anyway. Just because `WSGIDaemonProcess` is defined in `VirtualHost` doesn't mean it will be used automatically. – Graham Dumpleton Oct 20 '20 at 21:08
15

The way to get cerbot to do this for you and avoid the error without changing your config structure is to comment out the offending line. After certbot succeeds, you'll then need to edit the config files manually to uncomment the lines and make sure you choose a new daemon process name for the new HTTPS config. So, in this case you should:

  1. Put a # in front of the line starting with WSGIDaemonProcess.
  2. Run cerbot again and ask it to attempt to reinstall the existing cert for you. It will succeed this time.
  3. Edit the original configuration file and uncomment the WSGIDaemonProcess line.
  4. Edit the new configuration file that certbot created for you and uncomment the line (certbot will have copied the entire original config file for you, including any comments).
  5. You'll need to rename the daemon process in this file since you can't use the same name in two different virtual hosts; I'd recommend just adding an s to the name for secure: name -> names
  6. Restart Apache.
lxmmxl56
  • 492
  • 4
  • 10
  • the WSGIDaemonProcess could be required, this isn't a good solution ! – Aditya Shankar Nov 10 '19 at 15:37
  • 3
    @aditya-shankar I would say that it absolutely IS required...which is why you go back in and uncomment the line in step 3 and then restart apache again, making the WSGIDaemonProcess available again. – lxmmxl56 Nov 11 '19 at 08:58
  • 1. thats a really bad solution, multiple variables should NOT have the same name, 2. I don't really think that solution will actually work – Aditya Shankar Nov 11 '19 at 10:04
  • 1
    @aditya-shankar Sorry, it seems like my explanation wasn't good enough and I also assumed the user would be doing a redirect. You're absolutely right about multiple variables not having the same name, in fact they CANNOT have the same name and this is exactly why certbot fails. If you choose a redirect the original daemon process is no longer necessary and remains commented, so you only have one variable with that name. I updated the answer to work with or without a redirect and I've tested both scenarios to make sure they work. – lxmmxl56 Nov 12 '19 at 12:54
  • 2
    None of the solutions given here work for me. This one does, as undesirable as it is to do this manually. +1 – some-non-descript-user Nov 27 '19 at 12:57
  • 1
    Worked for me. I uncommented the line into the first file, restarted apache and it worked like a charm : ) you got my vote – snoob dogg Jan 12 '20 at 14:34
  • 1
    Excellent! The only solution that worked. The rest are fantasies or particular situations that happened to work – Bogdan Mar 08 '20 at 06:04
  • 1
    Have been very frustrated for days over this issue. I'm not clear on whether or not it is the best solution or will cause future issues, but it's the only solution that has worked for me. I'm making note of the steps here in case I ever need to backtrack but so far so good. Thanks, @lxmmxl56! – johnwonderbread Mar 31 '20 at 02:03
  • this one worked but I tweaked it a little. I used prot 443 instead of port 80, generated the ssl and then redirected. Kinda crude but does the job. – NegassaB Dec 10 '20 at 13:55