Prosody IM/how to/SSL - Revision history

Woozle at 15:10, 4 February 2021

2021-02-04T15:10:12Z

← Older revision		Revision as of 15:10, 4 February 2021
Line 1:		Line 1:
			Prosody actually has a command for importing root-owned certificates, en masse. Works specifically with Let's Encrypt. To be documented. [[User:Woozle\|Woozle]] ([[User talk:Woozle\|talk]]) 15:10, 4 February 2021 (UTC)
			==Old==
	In order to get Prosody to use an existing SSL certificate whose files belong to another user ("hypertwins"), I had to do the following:		In order to get Prosody to use an existing SSL certificate whose files belong to another user ("hypertwins"), I had to do the following:
	* edit (or create) the necessary config file under <code>/etc/prosody/conf.avail</code> and link to it from <code>/etc/prosody/conf.d</code>		* edit (or create) the necessary config file under <code>/etc/prosody/conf.avail</code> and link to it from <code>/etc/prosody/conf.d</code>

Woozle at 18:21, 31 October 2020

2020-10-31T18:21:57Z

← Older revision		Revision as of 18:21, 31 October 2020
Line 9:		Line 9:
	** You may also need to add www-data to the ssl-cert group so that Apache will still be able to access the virtual domain whose user is "hypertwins".		** You may also need to add www-data to the ssl-cert group so that Apache will still be able to access the virtual domain whose user is "hypertwins".
	** There were permissions issues; I had to use chown -h on the links -- this may also have been unnecessary, even if you're using links		** There were permissions issues; I had to use chown -h on the links -- this may also have been unnecessary, even if you're using links
	* restart prosody ~~("service prosody restart") ]~~		* {{l/same\|restart}} prosody
	** note that "reload" is apparently insufficient		** note that "reload" is apparently insufficient
	* If IM client gives SSL errors		* If IM client gives SSL errors

Woozle: /* 2017-09-30 */

2020-10-31T17:09:29Z

2017-09-30

← Older revision		Revision as of 17:09, 31 October 2020
Line 18:		Line 18:
	*** attempt to access the files. If you can see the contents, then prosody can also.		*** attempt to access the files. If you can see the contents, then prosody can also.
	==2017-09-30==		==2017-09-30==
	SSL stopped working again. Apparently the SSL files were renewed three days earlier (9/26) but not given the modified permissions, and it took 2-3 days for Prosody to notice. All I had to do was fix the ~~ownershop~~ ("chown :ssl-cert ssl.*"), "service prosody restart", and then tell Pidgin to reconnect.		SSL stopped working again. Apparently the SSL files were renewed three days earlier (9/26) but not given the modified permissions, and it took 2-3 days for Prosody to notice. All I had to do was fix the ownership ("chown :ssl-cert ssl.*"), "service prosody restart", and then tell Pidgin to reconnect.

	I should probably set up a script to do this automatically after the cert renewal.		I should probably set up a script to do this automatically after the cert renewal.

	==2018-12-06==		==2018-12-06==
	Script written awhile ago, now finally working right (this time): [[/prosody-cert-fix.php]]		Script written awhile ago, now finally working right (this time): [[/prosody-cert-fix.php]]

Woozle: script

2018-12-06T12:34:28Z

script

← Older revision		Revision as of 12:34, 6 December 2018
Line 1:		Line 1:
	In order to get Prosody to use an existing SSL certificate whose files belong to another user ("hypertwins"), I had to do the following:		In order to get Prosody to use an existing SSL certificate whose files belong to another user ("hypertwins"), I had to do the following:
	* edit (or create) the necessary config file under /etc/prosody/conf.avail and link to it from /etc/prosody/conf.d		* edit (or create) the necessary config file under <code>/etc/prosody/conf.avail</code> and link to it from <code>/etc/prosody/conf.d</code>
	** Do NOT activate the SSL section in /etc/prosody/prosody.cfg.lua		** Do NOT activate the SSL section in /etc/prosody/prosody.cfg.lua
	* make sure there is a group for sharing SSL certs (on my system, there was already a "ssl-cert" group)		* make sure there is a group for sharing SSL certs (on my system, there was already a "ssl-cert" group)
	* add user "prosody" to this group		* add user "prosody" to this group
	* for certificate files and /home/hypertwins:		* for certificate files and <code>/home/hypertwins:</code>
	** make sure the each one is are group-readable ([[chmod]] 750)		** make sure the each one is are group-readable ([[chmod]] 750)
	** chown to hypertwins:ssl-cert (so the group is ssl-cert)		** chown to hypertwins:ssl-cert (so the group is ssl-cert)
Line 12:		Line 12:
	** note that "reload" is apparently insufficient		** note that "reload" is apparently insufficient
	* If IM client gives SSL errors		* If IM client gives SSL errors
	** check /var/log/prosody.err		** check <code>/var/log/prosody.err</code>
	** check file access directly:		** check file access directly:
	*** change user prosody's shell from /bin/false to /bin/bash		*** change user prosody's shell from <code>/bin/false</code> to <code>/bin/bash</code>
	*** su prosody (as root)		*** su prosody (as root)
	*** attempt to access the files. If you can see the contents, then prosody can also.		*** attempt to access the files. If you can see the contents, then prosody can also.
Line 21:		Line 21:

	I should probably set up a script to do this automatically after the cert renewal.		I should probably set up a script to do this automatically after the cert renewal.
			==2018-12-06==
			Script written awhile ago, now finally working right (this time): [[/prosody-cert-fix.php]]

Woozle: /* 2017-09-30 */ punctuation

2017-09-30T10:49:16Z

2017-09-30: punctuation

← Older revision		Revision as of 10:49, 30 September 2017
Line 18:		Line 18:
	*** attempt to access the files. If you can see the contents, then prosody can also.		*** attempt to access the files. If you can see the contents, then prosody can also.
	==2017-09-30==		==2017-09-30==
	SSL stopped working again. Apparently the SSL files were renewed three days earlier (9/26) but not given the modified permissions, and it took 2-3 days for Prosody to notice. All I had to do was fix the ownershop (chown :ssl-cert ssl.*, "service prosody restart", and then tell Pidgin to reconnect.		SSL stopped working again. Apparently the SSL files were renewed three days earlier (9/26) but not given the modified permissions, and it took 2-3 days for Prosody to notice. All I had to do was fix the ownershop ("chown :ssl-cert ssl.*"), "service prosody restart", and then tell Pidgin to reconnect.

	I should probably set up a script to do this automatically after the cert renewal.		I should probably set up a script to do this automatically after the cert renewal.

Woozle: 9/30 fix

2017-09-30T10:48:43Z

9/30 fix

← Older revision		Revision as of 10:48, 30 September 2017
Line 8:		Line 8:
	** chown to hypertwins:ssl-cert (so the group is ssl-cert)		** chown to hypertwins:ssl-cert (so the group is ssl-cert)
	** You may also need to add www-data to the ssl-cert group so that Apache will still be able to access the virtual domain whose user is "hypertwins".		** You may also need to add www-data to the ssl-cert group so that Apache will still be able to access the virtual domain whose user is "hypertwins".
	* I also created links to the files and put the links in /etc/prosody/certs, but ultimately that may have been unnecessary
	** There were permissions issues; I had to use chown -h on the links -- this may also have been unnecessary, even if you're using links		** There were permissions issues; I had to use chown -h on the links -- this may also have been unnecessary, even if you're using links
	* restart prosody ("service prosody restart")		* restart prosody ("service prosody restart") ]
			** note that "reload" is apparently insufficient
	* If IM client gives SSL errors		* If IM client gives SSL errors
	** check /var/log/prosody.err		** check /var/log/prosody.err
Line 17:		Line 17:
	*** su prosody (as root)		*** su prosody (as root)
	*** attempt to access the files. If you can see the contents, then prosody can also.		*** attempt to access the files. If you can see the contents, then prosody can also.
			==2017-09-30==
			SSL stopped working again. Apparently the SSL files were renewed three days earlier (9/26) but not given the modified permissions, and it took 2-3 days for Prosody to notice. All I had to do was fix the ownershop (chown :ssl-cert ssl.*, "service prosody restart", and then tell Pidgin to reconnect.

			I should probably set up a script to do this automatically after the cert renewal.

Woozle: another caveat

2017-08-31T21:44:57Z

another caveat

← Older revision		Revision as of 21:44, 31 August 2017
Line 7:		Line 7:
	** make sure the each one is are group-readable ([[chmod]] 750)		** make sure the each one is are group-readable ([[chmod]] 750)
	** chown to hypertwins:ssl-cert (so the group is ssl-cert)		** chown to hypertwins:ssl-cert (so the group is ssl-cert)
			** You may also need to add www-data to the ssl-cert group so that Apache will still be able to access the virtual domain whose user is "hypertwins".
	* I also created links to the files and put the links in /etc/prosody/certs, but ultimately that may have been unnecessary		* I also created links to the files and put the links in /etc/prosody/certs, but ultimately that may have been unnecessary
	** There were permissions issues; I had to use chown -h on the links -- this may also have been unnecessary, even if you're using links		** There were permissions issues; I had to use chown -h on the links -- this may also have been unnecessary, even if you're using links

Woozle: Created page with "In order to get Prosody to use an existing SSL certificate whose files belong to another user ("hypertwins"), I had to do the following: * edit (or create) the necessary confi..."

2017-08-31T21:18:53Z

Created page with "In order to get Prosody to use an existing SSL certificate whose files belong to another user ("hypertwins"), I had to do the following: * edit (or create) the necessary confi..."

New page

In order to get Prosody to use an existing SSL certificate whose files belong to another user ("hypertwins"), I had to do the following:
* edit (or create) the necessary config file under /etc/prosody/conf.avail and link to it from /etc/prosody/conf.d
** Do NOT activate the SSL section in /etc/prosody/prosody.cfg.lua
* make sure there is a group for sharing SSL certs (on my system, there was already a "ssl-cert" group)
* add user "prosody" to this group
* for certificate files and /home/hypertwins:
** make sure the each one is are group-readable ([[chmod]] 750)
** chown to hypertwins:ssl-cert (so the group is ssl-cert)
* I also created links to the files and put the links in /etc/prosody/certs, but ultimately that may have been unnecessary
** There were permissions issues; I had to use chown -h on the links -- this may also have been unnecessary, even if you're using links
* restart prosody ("service prosody restart")
* If IM client gives SSL errors
** check /var/log/prosody.err
** check file access directly:
*** change user prosody's shell from /bin/false to /bin/bash
*** su prosody (as root)
*** attempt to access the files. If you can see the contents, then prosody can also.