https://wiki.archlinux.org/api.php?action=feedcontributions&user=Djanos&feedformat=atomArchWiki - User contributions [en]2024-03-28T16:53:35ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Certbot&diff=431115Certbot2016-04-13T20:31:59Z<p>Djanos: reload httpd is enough (i'm not sure for nginx)</p>
<hr />
<div>[[Category:Networking]]<br />
[[Category:Encryption]]<br />
[[ja:Let’s Encrypt]]<br />
[https://letsencrypt.org/ Let’s Encrypt] is a free, automated, and open certificate authority utilizing the ACME protocol. It provides tools to request valid ssl certificates straight from the command line.<br />
<br />
== Installation ==<br />
<br />
To obtain the official client [[install]] the {{Pkg|letsencrypt}} package.<br />
<br />
A minimal client with manual CSR creation is available at {{AUR|acme-tiny}}. More integrated clients suitable for scripts are e.g. {{AUR|simp_le-git}} and {{AUR|letsencrypt-cli}}.<br />
<br />
The official client provides plugins for automated configuration and installation of the issued certificates in web servers:<br />
* The experimental plugin for [[Nginx]] is provided with the {{Pkg|letsencrypt-nginx}} package.<br />
* Although a package {{Pkg|letsencrypt-apache}} exists, automated installation using the [[Apache HTTP Server]] is currently only supported on Debian and derivatives.<br />
<br />
== Configuration ==<br />
<br />
Please consult the [https://letsencrypt.readthedocs.org/en/latest/ Let’s Encrypt client documentation] on how to create and install certificates. This wiki will be expanded as soon as certificate installation methods have been crystallized out.<br />
<br />
=== Manual ===<br />
<br />
{{Note|With this method, you must temporarily stop your web server. You can also run the verification through your already running web server with the [[#Webroot]] method.}}<br />
<br />
If there is no plugin for your web server, use the following command:<br />
# letsencrypt certonly --manual<br />
<br />
This will automatically verify your domain and create a private key and certificate pair. These are placed in {{ic|/etc/letsencrypt/live/''your.domain''/}}.<br />
<br />
You can then manually configure your web server to use the key and certificate in that directory.<br />
<br />
=== Webroot ===<br />
<br />
The webroot method lets the client place a challenge response at {{ic|yourdomain.tld/.well-known/acme-challenge/}}.<br />
You can use it to get/renew certificates with a running webserver (e.g. Apache/nginx).<br />
# letsencrypt certonly --email ''email@example.com'' --webroot -w ''/path/to/html/'' -d ''your.domain''<br />
<br />
Make sure the server configuration for the certificates points to {{ic|/etc/letsencrypt/live/''your.domain''/}}.<br />
<br />
If you use more than one domain or subdomains, the webroot has to be given for every domain. If no new webroot is given, the previous is taken.<br />
<br />
Management of this can be made much easier, if you instruct you map all http requests for {{ic|/.well-known/acme-challenge/}} to a single folder, e.g. {{ic|/var/lib/letsencrypt}}.<br />
For nginx you can achieve this with a location block, placed e.g. in {{ic|ssl.conf}}:<br />
{{hc|ssl.conf|<nowiki><br />
location /.well-known/acme-challenge {<br />
alias /var/lib/letsencrypt;<br />
default_type "text/plain";<br />
try_files $uri =404;<br />
}</nowiki>}}<br />
For apache you can achieve this by creating the file {{ic|httpd-acme.conf}}:<br />
{{hc|/etc/httpd/conf/extra/httpd-acme.conf|<nowiki><br />
Alias /.well-known/acme-challenge/ "/var/lib/letsencrypt/.well-known/acme-challenge/"<br />
<Directory "/var/lib/letsencrypt/"><br />
AllowOverride None<br />
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec<br />
Require method GET POST OPTIONS<br />
</Directory><br />
</nowiki>}}<br />
and including it in {{ic|httpd.conf}}:<br />
{{hc|/etc/httpd/conf/httpd.conf|<nowiki><br />
Include conf/extra/httpd-acme.conf<br />
</nowiki>}}<br />
The chosen path has then to be writable for the chosen letsencrypt client. It also has to be readable by the web server; you can achieve this thereby : {{ic|chgrp http /val/lib/letsencrypt && chmod g+s /var/lib/letsencrypt}}.<br />
<br />
==== Automatic renewal ====<br />
<br />
When running {{ic|letsencrypt certonly}}, letsencrypt stores the domains and webroot directories in {{ic|/etc/letsencrypt/renewal}}, so the certificates can be renewed later automatically by running {{ic|letsencrypt renew}}.<br />
<br />
You can fully automate this by creating the following systemd service file:<br />
<br />
{{hc|1=/etc/systemd/system/letsencrypt.service|<br />
2=[Unit]<br />
Description=Let's Encrypt renewal<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/letsencrypt renew}}<br />
<br />
Before adding a [[systemd/Timers|timer]], check that the service is working correctly and is not trying to prompt anything.<br />
<br />
Then, you can add a timer to renew the certificates monthly.<br />
<br />
{{hc|1=/etc/systemd/system/letsencrypt.timer|<br />
2=[Unit]<br />
Description=Monthly renewal of Let's Encrypt's certificates<br />
<br />
[Timer]<br />
OnCalendar=monthly<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=timers.target}}<br />
<br />
[[Enable]] and [[start]] {{ic|letsencrypt.timer}}.<br />
<br />
You'll probably want your web server to be restarted after each certificate renewal. You can realize that by adding one of these lines to the {{ic|letsencrypt.service}} file:<br />
<br />
* Apache: {{ic|1=ExecStartPost=/usr/sbin/systemctl reload httpd.service}}<br />
* nginx: {{ic|1=ExecStartPost=/usr/sbin/systemctl restart nginx.service}}<br />
<br />
== See also ==<br />
<br />
* [https://community.letsencrypt.org/t/list-of-client-implementations/2103 List of ACME clients]</div>Djanoshttps://wiki.archlinux.org/index.php?title=Certbot&diff=431114Certbot2016-04-13T20:30:32Z<p>Djanos: challenge alias for apache</p>
<hr />
<div>[[Category:Networking]]<br />
[[Category:Encryption]]<br />
[[ja:Let’s Encrypt]]<br />
[https://letsencrypt.org/ Let’s Encrypt] is a free, automated, and open certificate authority utilizing the ACME protocol. It provides tools to request valid ssl certificates straight from the command line.<br />
<br />
== Installation ==<br />
<br />
To obtain the official client [[install]] the {{Pkg|letsencrypt}} package.<br />
<br />
A minimal client with manual CSR creation is available at {{AUR|acme-tiny}}. More integrated clients suitable for scripts are e.g. {{AUR|simp_le-git}} and {{AUR|letsencrypt-cli}}.<br />
<br />
The official client provides plugins for automated configuration and installation of the issued certificates in web servers:<br />
* The experimental plugin for [[Nginx]] is provided with the {{Pkg|letsencrypt-nginx}} package.<br />
* Although a package {{Pkg|letsencrypt-apache}} exists, automated installation using the [[Apache HTTP Server]] is currently only supported on Debian and derivatives.<br />
<br />
== Configuration ==<br />
<br />
Please consult the [https://letsencrypt.readthedocs.org/en/latest/ Let’s Encrypt client documentation] on how to create and install certificates. This wiki will be expanded as soon as certificate installation methods have been crystallized out.<br />
<br />
=== Manual ===<br />
<br />
{{Note|With this method, you must temporarily stop your web server. You can also run the verification through your already running web server with the [[#Webroot]] method.}}<br />
<br />
If there is no plugin for your web server, use the following command:<br />
# letsencrypt certonly --manual<br />
<br />
This will automatically verify your domain and create a private key and certificate pair. These are placed in {{ic|/etc/letsencrypt/live/''your.domain''/}}.<br />
<br />
You can then manually configure your web server to use the key and certificate in that directory.<br />
<br />
=== Webroot ===<br />
<br />
The webroot method lets the client place a challenge response at {{ic|yourdomain.tld/.well-known/acme-challenge/}}.<br />
You can use it to get/renew certificates with a running webserver (e.g. Apache/nginx).<br />
# letsencrypt certonly --email ''email@example.com'' --webroot -w ''/path/to/html/'' -d ''your.domain''<br />
<br />
Make sure the server configuration for the certificates points to {{ic|/etc/letsencrypt/live/''your.domain''/}}.<br />
<br />
If you use more than one domain or subdomains, the webroot has to be given for every domain. If no new webroot is given, the previous is taken.<br />
<br />
Management of this can be made much easier, if you instruct you map all http requests for {{ic|/.well-known/acme-challenge/}} to a single folder, e.g. {{ic|/var/lib/letsencrypt}}.<br />
For nginx you can achieve this with a location block, placed e.g. in {{ic|ssl.conf}}:<br />
{{hc|ssl.conf|<nowiki><br />
location /.well-known/acme-challenge {<br />
alias /var/lib/letsencrypt;<br />
default_type "text/plain";<br />
try_files $uri =404;<br />
}</nowiki>}}<br />
For apache you can achieve this by creating the file {{ic|httpd-acme.conf}}:<br />
{{hc|/etc/httpd/conf/extra/httpd-acme.conf|<nowiki><br />
Alias /.well-known/acme-challenge/ "/var/lib/letsencrypt/.well-known/acme-challenge/"<br />
<Directory "/var/lib/letsencrypt/"><br />
AllowOverride None<br />
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec<br />
Require method GET POST OPTIONS<br />
</Directory><br />
</nowiki>}}<br />
and including it in {{ic|httpd.conf}}:<br />
{{hc|/etc/httpd/conf/httpd.conf|<nowiki><br />
Include conf/extra/httpd-acme.conf<br />
</nowiki>}}<br />
The chosen path has then to be writable for the chosen letsencrypt client. It also has to be readable by the web server; you can achieve this thereby : {{ic|chgrp http /val/lib/letsencrypt && chmod g+s /var/lib/letsencrypt}}.<br />
<br />
==== Automatic renewal ====<br />
<br />
When running {{ic|letsencrypt certonly}}, letsencrypt stores the domains and webroot directories in {{ic|/etc/letsencrypt/renewal}}, so the certificates can be renewed later automatically by running {{ic|letsencrypt renew}}.<br />
<br />
You can fully automate this by creating the following systemd service file:<br />
<br />
{{hc|1=/etc/systemd/system/letsencrypt.service|<br />
2=[Unit]<br />
Description=Let's Encrypt renewal<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/letsencrypt renew}}<br />
<br />
Before adding a [[systemd/Timers|timer]], check that the service is working correctly and is not trying to prompt anything.<br />
<br />
Then, you can add a timer to renew the certificates monthly.<br />
<br />
{{hc|1=/etc/systemd/system/letsencrypt.timer|<br />
2=[Unit]<br />
Description=Monthly renewal of Let's Encrypt's certificates<br />
<br />
[Timer]<br />
OnCalendar=monthly<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=timers.target}}<br />
<br />
[[Enable]] and [[start]] {{ic|letsencrypt.timer}}.<br />
<br />
You'll probably want your web server to be restarted after each certificate renewal. You can realize that by adding one of these lines to the {{ic|letsencrypt.service}} file:<br />
<br />
* Apache: {{ic|1=ExecStartPost=/usr/sbin/systemctl restart httpd.service}}<br />
* nginx: {{ic|1=ExecStartPost=/usr/sbin/systemctl restart nginx.service}}<br />
<br />
== See also ==<br />
<br />
* [https://community.letsencrypt.org/t/list-of-client-implementations/2103 List of ACME clients]</div>Djanoshttps://wiki.archlinux.org/index.php?title=OpenLDAP_Authentication&diff=263182OpenLDAP Authentication2013-06-18T03:45:16Z<p>Djanos: reading —> writing</p>
<hr />
<div>[[Category:Networking]] [[Category:Security]]<br />
{{Out_of_date|pam_ldap/nss_ldap are deprecated in favor of {{pkg|nss-pam-ldapd}}; {{pkg|pambase}} obsoletes most of the pam section}}<br />
{{Merge|LDAP Authentication}}<br />
== Introduction and Concepts ==<br />
<br />
This is a guide on how to configure an Archlinux installation to authenticate against an OpenLDAP server.The openldap backend can be either local (installed on the same computer) or network (i.e in a lab environment where central authentication is desired).<br />
The guide will be divided in two parts. The first part deals with how to setup OpenLDAP locally and the second with how to setup the NSS and PAM modules required for the authentication scheme to work. If you just want to configure Arch to authenticated against an already excisting LDAP server then you can skip to the second part.<br />
<br />
=== OpenLDAP ===<br />
<br />
OpenLDAP is an open-source server implementation of the LDAP protocol. It is mainly used as an authentication backend to various services (the most famous one being Samba, which is used to emulate a domain controller) and basically holds the user data.<br />
The closest analogue to real life, would be the telephone directory. Another generalised explanation of what an LDAP server does is that it is a database (which it basically is, but it is not relational) which is optimised for accessing the data and not writing them.<br />
<br />
Commands relate to OpenLDAP that begin with ldap (like ldapsearch) are client-side utilities while commands that begin with slap (like slapcat) are server-side. Arch packages both in the {{pkg|openldap}} package, so you need to install it regardless of o local or network OpenLDAP install.<br />
<br />
=== NSS and PAM ===<br />
<br />
NSS (which stands for Name Service Switch) is a system mechanism to configure different sources for common configuration databases. For example, {{ic|/etc/passwd}} is a {{ic|file}} type source for the passwd database.<br />
<br />
PAM (which stands for Pluggable Authentication Module) is a machanism Linux (and most *nixes) uses to extend it's authentication schemes based on different plugins.<br />
<br />
So to summarize, we need to configure NSS to use the OpenLDAP server as a source for the {{ic|passwd}} {{ic|shadow}} and other configuration databases and then configure PAM to use these sources to authenticate it's users.<br />
<br />
== OpenLDAP Setup ==<br />
<br />
=== Installation ===<br />
<br />
You can read about installation and basic configuration in the [[OpenLDAP]] article. After you have completed that, return here.<br />
<br />
=== Populate LDAP Tree with Base Data ===<br />
<br />
Create a file called base.ldif with the following text:<br />
<br />
# example.org<br />
dn: dc=example,dc=org<br />
objectClass: dcObject<br />
objectClass: organization<br />
o: Example Organization<br />
dc: example<br />
<br />
# Manager, example.org<br />
dn: cn=Manager,dc=example,dc=org<br />
cn: Manager<br />
description: LDAP administrator<br />
roleOccupant: dc=example,dc=org<br />
objectClass: organizationalRole<br />
objectClass: top<br />
<br />
# People, example.org<br />
dn: ou=People,dc=example,dc=org<br />
ou: People<br />
objectClass: top<br />
objectClass: organizationalUnit<br />
<br />
# Group, example.org<br />
dn: ou=Group,dc=example,dc=org<br />
ou: Group<br />
objectClass: top<br />
objectClass: organizationalUnit<br />
<br />
Add it to your OpenLDAP Tree:<br />
<br />
ldapadd -x -D "cn=Manager,dc=example,dc=org" -W -f base.ldif<br />
<br />
Test to make sure the data was imported:<br />
<br />
ldapsearch -x -b 'dc=example,dc=org' '(objectclass=*)'<br />
<br />
<br />
== Client Setup ==<br />
<br />
[[pacman|Install]] {{Pkg|openldap}} from the [[official repositories]]. This is needed regardless of whether you run openldap on your machine or over the network.<br />
<br />
Next, [[pacman|install]] {{AUR|nss-pam-ldapd}} from the [[Arch User Repository]].<br />
<br />
There is the {{pkg|nss_ldap}} and {{pkg|pam_ldap}} from the [[Official Repositories|official repositories]] <br />
<br />
=== OpenLDAP ===<br />
Before you begin setting up PAM and NSS for ldap authentication, you should try to check if the LDAP server is available. You can do this easily with ldapsearch.<br />
<br />
You can search an LDAP server with the following command:<br />
{{bc|ldapsearch -x -H <URL> -b <BASE>}}<br />
{{Tip| {{ic|-x}} is required in all client commands because SASL authentication probably hasn't been configured.}}<br />
<br />
You can add the URL and BASE settings to {{ic|/etc/openldap/ldap.conf}} in order to avoid writing the everytime. All client-side ldap utilities use this file to read some general variables.<br />
{{Warning| If you created a self-signed certificate above you need to also add the following line or you will not be able connect to the server:<br />
{{ic|TLS_REQCERT allow}} }}<br />
<br />
=== NSS Configuration ===<br />
NSS is a system facility which manages different sources as configuration databases. For example {{ic|/etc/passwd}} is i {{ic|file}}-type source for the {{ic|passwd}} which by default stores the user accounts. nss_ldap is a plugin which allow NSS to see an OpenLDAP server as a source for these databases.<br />
<br />
Edit {{ic|/etc/nsswitch.conf}} which is the central configuration file for NSS. It tells NSS which sources to use for which system databases. We need to add the {{ic|ldap}} directive to the {{ic|passwd}}, {{ic|group}} and {{ic|shadow}} databases, so be sure your file looks like this:<br />
<br />
passwd: files ldap<br />
group: files ldap<br />
shadow: files ldap<br />
<br />
==== Name Service Cache Daemon ====<br />
NSCD is a daemon that NSS runs that is responsible for caching lookups and queries for network backends.<br />
<br />
{{Note|It is recommended to stop the daemon when troubleshooting because it may mask problems by serving cached queries}}<br />
<br />
READ THIS FIRST: [[https://bbs.archlinux.org/viewtopic.php?id=9401 NSCD Bugged in Arch Linux]]<br />
Fix nscd:<br />
<br />
mkdir -p /var/db/nscd/<br />
mkdir -p /var/run/nscd/<br />
<br />
Run nscd:<br />
# systemctl start nscd<br />
<br />
==== NSLCD ====<br />
<br />
=== PAM Configuration ===<br />
<br />
Edit {{ic|/etc/pam.d/login}}:<br />
<br />
auth requisite pam_securetty.so<br />
auth requisite pam_nologin.so<br />
auth sufficient pam_ldap.so <br />
auth required pam_env.so<br />
auth required pam_unix.so nullok try_first_pass<br />
account sufficient pam_ldap.so<br />
account required pam_access.so<br />
account required pam_unix.so<br />
session required pam_motd.so<br />
session required pam_limits.so<br />
session optional pam_mail.so dir=/var/spool/mail standard<br />
session optional pam_lastlog.so<br />
session required pam_unix.so<br />
<br />
Edit {{ic|/etc/pam.d/passwd}}:<br />
<br />
password sufficient pam_ldap.so<br />
password required pam_unix.so shadow md5 nullok<br />
<br />
Edit {{ic|/etc/pam.d/shadow}}:<br />
<br />
auth sufficient pam_ldap.so<br />
auth sufficient pam_rootok.so<br />
auth required pam_unix.so<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
session sufficient pam_ldap.so<br />
session required pam_unix.so<br />
password sufficient pam_ldap.so<br />
password required pam_permit.so<br />
<br />
edit {{ic|/etc/pam.d/su}}:<br />
<br />
auth sufficient pam_ldap.so<br />
auth sufficient pam_rootok.so<br />
auth required pam_unix.so use_first_pass<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
session sufficient pam_ldap.so<br />
session required pam_unix.so<br />
<br />
edit {{ic|/etc/pam.d/sshd}}:<br />
<br />
auth sufficient pam_ldap.so<br />
auth required pam_securetty.so #Disable remote root<br />
auth required pam_unix.so try_first_pass<br />
auth required pam_nologin.so<br />
auth required pam_env.so<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
account required pam_time.so<br />
password sufficient pam_ldap.so<br />
password required pam_unix.so<br />
session required pam_unix_session.so<br />
session required pam_limits.so<br />
<br />
edit {{ic|/etc/pam.d/other}}:<br />
<br />
auth sufficient pam_ldap.so<br />
auth required pam_unix.so<br />
account sufficient pam_ldap.so<br />
account required pam_unix.so<br />
password sufficient pam_ldap.so<br />
password required pam_unix.so<br />
session required pam_unix.so<br />
<br />
== Resources ==<br />
[http://arthurdejong.org/nss-pam-ldapd/setup The official page of the nss-pam-ldapd packet]<br />
<br />
The PAM and NSS page at the Debian Wiki [http://wiki.debian.org/LDAP/NSS 1] [http://wiki.debian.org/LDAP/PAM 2]<br />
<br />
[http://www.fatofthelan.com/articles/articles.php?pid=24 Using LDAP for single authentication]<br />
<br />
[http://www.cs.dixie.edu/ldap/ Heterogeneous Network Authentication Introduction]<br />
<br />
[http://readlist.com/lists/suse.com/suse-linux-e/36/182642.html Discussion on suse's mailing lists about nss-pam-ldapd]</div>Djanos