Categories
System Administration

Installing SSL-certificates on Debian

Installing and configuring SSL certificates is always an issue as to how to create them and where to store them. Most of the time people can find the procedure on how to create them, but they forget all the places where they have placed them. Some initiatives exist to have centralized key stores on systems, but getting applications to use them is still a problem.

Also on Debian is this an issue and key material is all over the system if you’re not careful. Some Debian developers tried to fix it, but it ended in a “stalemate” and for now, an additional package called ssl-cert exists to create self-signed certificates. This package also provides a structure for storing commercial certificates and accessing them in a safer way. So for we install the package ssl-cert.

$ sudo apt-get install ssl-cert

After installing the package the different files for the SSL-key can be placed in /etc/ssl/private and have the right permissions as shown in the output below. This to protect the key material from being used by unauthorized processes as most keys don’t have a passphrase.

$ sudo ls -l /etc/ssl/private
-r--r----- 1 root    ssl-cert 2766 Dec 12 13:06 www.example.org_ca.pem
-r--r----- 1 root    ssl-cert 1671 Dec 12 13:06 www.example.org.crt
-r--r----- 1 root    ssl-cert 1070 Dec 12 13:06 www.example.org.csr
-r--r----- 1 root    ssl-cert 6268 Dec 12 13:06 www.example.org_intermediate.pem
-r--r----- 1 root    ssl-cert 1675 Dec 12 13:06 www.example.org.key
-r--r----- 1 root    ssl-cert 3502 Dec 12 13:06 www.example.org.pem

The location and files can only be accessed by the root user or members of the group ssl-cert. Some applications as Apache startup under the root user and access the files before switching to the actual user like www-data on Debian. For those applications, nothing is going to change, but for others like ejabberd that run completely under the ejabberd user, somethings change. Those users need to be made a member of the group ssl-cert to read the files in /etc/ssl/private. Below two known services are made members of the group ssl-cert read the certificates.

$ sudo usermod -a -G ssl-cert ejabberd
$ sudo usermod -a -G ssl-cert postgres
$ id -a ejabberd
uid=123(ejabberd) gid=125(ejabberd) groups=105(ssl-cert),125(ejabberd)
$ id -a postgres
uid=105(postgres) gid=108(postgres) groups=105(ssl-cert),108(postgres)

After checking the modification was in effect as some servers use a Naming Service Caching Daemon the affected services need to be restarted. In this example, both ejabberd and PostgreSQL need to restart before the SSL certificates can be accessed.

Categories
Internet, Unix en security

Interessante PKI vraagstukken

Security.nl heeft met artikel SSL niet bestand tegen afluisteren overheid een leuke ingang gegeven naar het failliet van X.509. Het doet me ook denken aan de presentatie van
Dan Kaminsky tijdens 26C3.



Eigenlijk is CAcert al failliet en de komende X.509 certificaten van de overheid zijn dus eigenlijk ook een uitdaging aan het worden. Helaas is PGP niet veel beter en minder goed inzetbaar dan X.509-certificaten.

Categories
Privacy & veiligheid Technologie & techniek

OpenPGP en SHA1

Dat MD5 namespace collissions had welke steeds serieuzere vormen begon aan te nemen was al een feit en voor SHA-1 waren ook al problemen te voorzien aan de toekomst. Helaas lijken voor SHA-1 de vorderingen sinds november 2008 en nu zo snel te gaan dat het een probleem begint te vormen zoals ook uit een posting is te halen:

Last week at eurocrypt, a small group of researchers announced a fairly serious attack against the SHA-1 digest algorithm, which is used in many cryptosystems, including OpenPGP. The general consensus is that we should be moving in an orderly fashion toward the theater exits, deprecating SHA-1 where possible with an eye toward abandoning it soon (one point of reference: US gov’t federal agencies have been directed to cease all reliance on SHA-1 by the end of 2010, and this directive was issued before the latest results).

Vooral de regel dat de Verenigde Staten van Amerika SHA-1 voor het einde van 2010 in de ban doet geeft mogelijk aan hoe serieus de zaak is. En met oa de MD5 problemen in veel X.509-certificaten nog vers in het achterhoofd wordt het misschien tijd om sommige hashing- en encryptiemethodieken in de ban te doen.

En hoewel het eerste gedeelte van de oplossing nog redelijk onschuldig is met de aanpassingen van de voorkeuren blijft de vraag was er bij het tweede gedeelte te winnen is nu. Zeker aangezien dat het een stuk verder ingrijpt dan nu mogelijk wordt voorgeschoteld. Om binnen 90 dagen over te stappen gaat veel problemen opleveren in the-web-of-trust waarbij de vraag misschien ontstaat of X.509-certificaten zoals van CACert geen betere lange termijn oplossing blijken. Maar een ding is wel duidelijk en dat is dat er meer speelt dan nu duidelijk is aangezien de VS op hoog tempo nu ook SHA-1 wil uitfaseren en sommige protocollen zoals DNS over wil hebben naar DNSSEC.