SSL leicht gemacht – CSR und Keyfile erstellen und Zertifikat ordern

This entry is part 1 of 1 in the series SSL leicht gemacht

Oftmals kommt trotz der breiten Verfügbarkeit von Letsencrypt der Wunsch nach kostenpflichtigen Zertifikaten auf. Die Gründe sind vielfältig: längere Gültigkeit, Wildcard-, Multidomain- oder Extended-Validation (Grüne-Leiste) Zertifikate – all das bietet Letsencrypt leider nicht und deshalb ist der Bedarf nach solchen Zertifikaten noch immer vorhanden. In den nächsten Wochen werden wir immer wieder Blogposts zum Thema SSL erstellen, alle zu finden in unserer Serie “SSL leicht gemacht”

Zu aller Anfang wird ein CSR (Certificate Signing Request) und ein Keyfile (privater Schlüssel) benötigt. Aus Sicherheitsgründen empfehlen wir prinzipiell die Erstellung gleich auf dem Zielsystem des Zertifikates vorzunehmen, so müssen die Daten nicht umgezogen werden und bleiben nicht “zufällig” irgendwo liegen.

Los geht’s mit dem Kommando

openssl req -new -nodes -keyout netways.de.key -out netways.de.csr -newkey rsa:4096

Dadurch wird im aktuellen Verzeichnis ein Privatekey mit einer Schlüssellänge von 4096 Bit (default 2048) angelegt. Der folgende Wizard sammelt nun noch die Daten für das CSR ein.

Hier wird nach dem Land, dem Staat, der Stadt, der Firma, der Abteilung, der zu sichernden Domain und der Kontaktmailadresse gefragt. Eingaben können auch leergelassen werden und mit der Eingabetaste übersprungen werden (ACHTUNG: Defaultwerte (sofern vorhanden) aus den eckigen Klammern werden übernommen).

Zur Kontrolle kann das CSR noch mit dem Kommando

openssl req -in netways.de.csr -noout -text

überprüft werden. Übrigens gibt es bei Umlauten (wie so oft) Probleme. Wir vermeiden diese gern durch die Verwendung englischer Städtenamen wie im aktuellen Beispiel zu sehen.
Abschließend kontrollieren wir das Keyfile noch (zumindest, ob es so in der Art aussieht).

Fertig, nun geht man zur Bestellung des Zertifikates über. Hierzu kann man auf jeden beliebigen Zertifikatshändler zurückgreifen. Wegen anhaltender “Unstimmigkeiten” bei Google und Symantec empfehle ich persönlich (bei der Neubestellung) auf Produkte von Comodo zurückzugreifen. Die Comodo-Zertifikate sind preislich im Mittelfeld und die Akzeptanz der Zertifikate ist hoch. Für die Bestellung wird nur der CSR benötigt. Das Keyfile sollte keinesfalls an irgendjemanden weitergegeben werden und auf dem Server verbleiben.

Bei der Bestellung werden nochmal alle möglichen Daten, gewünschte Laufzeit usw. abgefragt. Unter anderem auch die Mailadresse. Die Auswahlmöglichkeiten dieser ist oftmals beschränkt. Die ausgewählte Mailadresse muss zwingend verfügbar sein, um die Validierung via Mail abzuschließen und ein Zertifikat zu erhalten. Sofern alles geklappt hat, bekommt man später in der Regel per Mail das Zertifikat und ggf. das CA-Bundle zugeschickt.

Wie das alles nun zusammen eingerichtet wird, schreibe ich im nächsten Artikel.

Georg Mimietz

Autor: Georg Mimietz

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Redis vs MongoDB as message queue and config proxy

Benchmarks and comparisons for these two NoSQL databases exist a plenty. But in all the blogs and whitepapers I found the use-case was quite different from ours, we were trying to find a tool to queue Icinga 2 events and speed up config updates. The queue would use Redis Pub/Sub or MongoDBs capped collections + tailable cursors. From an implementation standpoint MongoDB looks better, it offers good libraries for most programming languages and the document-based approach allows for filtering based on individual attributes while values in Redis are just opaque blobs. Redis Pub/Sub model also has the problem that it loses its queued items when restarted.

From these naive benchmarks (PHP scripts run with time), it looks like MongoDB likes to take their time with creating objects.

Inserting 250.000 objects:

  • Redis: 11.1s
  • MongoDB: InsertOne: 53.3s
  • MongoDB: InsertMany: 25.4s

Inserting 250.000 objects into list capped to 50.000

  • Redis: 12s
  • MongoDB: InsertOne: 57.6s

Redis speed advantage comes from keeping created objects in memory, while MongoDB writes them to the hard drive right away. This is a huge advantage for Redis, as we rotate our events from the queue, writing them to disk would be a waste of io time. But sadly MongoDB does not offer the possibility of keeping the data volatile in memory.

Another concern of ours is security, Redis does not offer any security features and for many application this is not a problem, but in our case, this means we have to finds ways to make it secure. There have been many attempts to do so, e.g using tools like stunnel, but it’s still an additional topic that would need to be tackled. MongoDB on the other hand offers ACLs on document level and native SSL, which is great! Yet is has been rightfully criticized for its insecure default configurations, which resulted in a flood of hacked MongoDB instances earlier this year.

Conclusion: We will have to investigate further. Especially integration and security will need a closer look. MongoDBs performance seems lackluster, but may just be enough as our tests may have been much bigger than what we will be met with in a real setup.

Jean-Marcel Flach

Autor: Jean-Marcel Flach

Auch wenn man Anderes vermuten möchte: Jean ist nicht unser französischer Austauschazubi, sondern waschechter Bamberger. Die Uni war ihm zu langweilig, deshalb knöpft er sich nun im Development gleich die kniffligsten Aufgaben vor.

Store passwords like a boss #2

Als Programmierer von Webanwendungen, die Ihre Benutzer selbst verwalten, kommt man um das Thema Sicherheit nicht herum – so auch ich als Mitentwickler von Icinga Web 2.

Aus diesem Anlass habe ich recherchiert, wie Passwörter von Benutzern sinnvoll gespeichert werden können und mein neu gewonnenes Wissen geteilt.

Darüber hinaus habe ich vorgeschlagen, Icinga Web 2 dementsprechend zu erweitern. Eric hat diesen Vorschlag begutachtet und mich auf eine Alternative aufmerksam gemacht, nämlich…

password_hash()

PHP bietet seit Version 5.5 u. a. diese Funktion, um Passwörter zu verschlüsseln. Diese ersetzt meine selbst geschriebene Funktion aus dem Vorgänger-Blogpost vollständig:

$encryptedNewPassword = password_hash($newPassword, PASSWORD_DEFAULT);

Der Rückgabe-Wert kann direkt in einer Datenbank gespeichert werden – so einfach ist das.

Der zweite Parameter der Funktion bestimmt den Verschlüsselungs-Algorithmus. Damit kann man diesen zwar frei wählen, aber ich empfehle, den Standard vorzuziehen, denn dieser ändert sich (laut Doku) mit neueren PHP-Versionen zu Gunsten der Sicherheit. Damit bleiben zumindest die neuen/geänderten Passwörter aktuell was die Sicherheit angeht.

password_verify()

Wie der Name schon andeutet, überprüft diese Funktion ein vom Benutzer eingegebenes Passwort auf Übereinstimmung mit einem verschlüsselten Passwort:

$ok = password_verify($enteredPassword, $encryptedPassword);
if ($ok) {
    ...

password_needs_rehash()

Wie bereits erläutert: mit einem neuen Standard-Verschlüsselungs-Algorithmus werden automatisch alle neu verschlüsselten Passwörter sicherer. Aber was ist mit den bereits bestehenden?

Da bestehende Passwörter (aus gutem Grund!) nur verschlüsselt vorliegen, können sie nicht alle “in einem Abwasch” migriert werden. Die einzige Gelegenheit ist die Anmeldung eines Benutzers, die das Klartext-Passwort erfordert. Und als wäre die Funktion für diese Gelegenheit geschrieben…

if ($ok) {
    $outdated = password_needs_rehash($encryptedPassword, PASSWORD_DEFAULT);
    if ($outdated) {
        $encryptedPassword = password_hash($enteredPassword, PASSWORD_DEFAULT);
    }
    ...

Fazit

Der IT-Branche wird nicht umsonst nachgesagt, dass sie eine “permanente Innovation” vollbringe. Umso wichtiger ist es, aus Gründen der Datensicherheit, mit der dunklen Seite der Macht mitzuhalten.

Denn die sind böse, sehr böse…

Alexander Klimov

Autor: Alexander Klimov

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Chrome, certificates and missing_subjectAltNames Part 2 of 1

Actually I wanted to cover this topic in the previous post, but somehow have missed it.

Using the mentioned one liner can lead to typos and/or some strange behaviour on the CA side, especially when using a Windows-CA.

To circumvent this issues, I mentioned “a specially designed *.conf file” which I’d like to elaborate today.

Following steps are necessary:

Create a file “req.conf” in etc/ssl/ (Ubuntu 14.04, pathes may vary) with the following content:

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = $YourTLD
ST = $YourState
L = $YourCity
O = $YourCompany
OU = $YourDepatment
CN = $YourCName (e.g. internal.company.tld)
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = *.internal.company.tld
DNS.2 = internal.company.tld
DNS.3 = www.*.internal.company.tld

Essentially, these are the information provided by the “-subj section” in last weeks one liner.

Now you can generate a key:

openssl genrsa -out internal.company.tld.key 4096

and use your new key and the req.conf file to generate a CSR, which, as usually can be fed into your local CA.

openssl req -new -out internal.company.tld.csr -key internal.company.de.key -config req.conf -sha256

This *.conf file can be used as a template for other C/altNames as well and is, in my eyes, more lucid than a one liner.

Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Chrome, certificates and missing_subjectAltNames

Google has been actively trying to ensure certificate security especially in the last months.

Sometimes this created quite some buzz in the IT World, e.g. when Symantecs policies came into the focus.

Current version 58 of Google Chrome has again adjusted the certificate policy.

Certificates provide two ways to store hostnames: CommonName and SubjectAltName (SAN). RFC 2818 specified in 2000 that CommonName should be deprecated, which Chrome now complies to.

Other browsers are currently still accepting the CommonName, which is mostly used by selfsigned certificates, as in our case :/

Users who wanted to access our internal sites encountered error messages and were forced to use quick and dirty workarounds, such as using a Windows registry “hack”:

Open a cmd-Shell as Administrator and enter:

reg add \HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome /v EnableCommonNameFallbackForLocalAnchors /t REG_DWORD /d 1 /f

which reactivates the fallback to CommonName

As this is just a temporary “solution”, you should issue an RFC 2818 conform certificate. This can be realized by using a complete and compliant certificate signing request (CSR).

You can either use a specially designed *.conf File for this or simply adapt the following shell command:

openssl req -new-key endpoint.com.key -sha256 -nodes  -subj '/C=US/ST=New York/L=New York/O=End Point/OU=Hosting Team/CN=www.endpoint.com/
         emailAddress=administrative-not-existent-address@our-awesome-domain.com/
         subjectAltName=DNS.1=endpoint.com,
         DNS.2=usually-not-convered-domain.endpoint.com,
         DNS.3=multiple-domains-crt.endpoint.com' > www.endpoint.com.csr
The created csr can be fed e.g. into your local CA to issue new certificates which can be rolled out in your environment.
Live long and prosper and be RFC compliant 🙂
Tim Albert

Autor: Tim Albert

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere um Infrastrukturthemen kümmert. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr - als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit einsatzbereit. Ansonsten kocht er sehr gerne – alles außer Hase!

Like meeting the family – OSDC 2017: Day 1

OSDC Logo
I was happy to join our conference crew for OSDC 2017 again because it is like meeting the family as one of our attendees said. Conference started for me already yesterday because I could join Gabriel‘s workshop on Mesos Marathon. It was a quite interesting introduction into this topic with examples and know how from building our Software-As-A-Service platform “Netways Web Services“. But it was also very nice to meet many customers and long-time attendees again as I already knew more than half of the people joining the workshops. So day zero ended with some nice conversation at the hotel’s restaurant.

As always the conference started with a warm welcome from Bernd before the actual talks (and the hard decision which talk to join) started. For the first session I joined Daniel Korn from Red Hat’s Container Management Team on “Automating your data-center with Ansible and ManageIQ“. He gave us an good look behind “one management solution to rule them all” like ManageIQ (the upstream version of Red Hat Cloudform) which is designed as an Open source management platform for Hybrid IT. So it integrates many different solutions like Openshift, Foreman or Ansible Tower in one interface. And as no one wants to configure such things manually today there are some Ansible modules to help with automating the setup. Another topic covered was Hawkular a time series database including triggers and alarming which could be used get alerts from Openshift to ManageIQ.

The second talk was Seth Vargo with “Taming the Modern Data Center” on how to handle the complexity of data centers today. He also covered the issues of life cycles shrinking from timeframes measured in days, weeks and month to seconds and minutes and budget moving from CapEx to OpEx by using cloud or service platforms. With Terraform he introduced one of HashiCorp’s solutions to help with solving these challenges by providing one abstraction layer to manage multiple solutions. Packer was another tool introduced to help with image creation for immutable infrastructure. The third tool shown was Consul providing Service Discovery (utilizing DNS or a HTTP API), Health Checking (and automatic removal from discovered services), Key/Value Store (as configuration backend for these services) and Multi-Datacenter (for delegating service request to nearest available system). In addition Seth gave some good look inside workflows and concepts inside HashCorp like they use their own software and test betas in production before releasing or trust developers of the integrated software to maintain the providers required for this integration.

Next was Mandi Walls on “Building Security Into Your Workflow with InSpec”. The problem she mentioned and is tried to be resolved by InSpec is security reviews can slow down development but moving security reviews to scanning a production environment is to late. So InSpec is giving the administrator a spec dialect to write human-readable compliance tests for Linux and Windows. It addresses being understandable for non-technical compliance officers by doing so and profiles give them a catalog to satisfy all their needs at once. If you want an example have a look at the chef cookbook os-hardening and the InSpec profile /dev-sec/linux-baseline working nicely together by checking compliance and running remediation.

James Shubin giving a big life demo of mgmt was entertaining and informative as always. I have already seen some of the demos on other events, but it is still exciting to see configuration management with parallelization (no unnecessary waiting for resources), event driven (instant recreation of resources), distributed topology (no single point of failure), automatic grouping of resource (no more running the package manager for every package), virtual machines as resources (including managing them from cockpit and hot plug cpus), remote execution (allowing to spread configuration management through SSH from one laptop over your data center). mgmt is not production ready for now, but its very promising. Future work includes a descriptive language, more resource types and more improvements. I can recommend watching the recording when it goes online in the next days.

“Do you trust your containers?” was the question asked by Erez Freiberger in his talk before he gave the audience some tools to increase the trust. After a short introduction into SCAP and OpenSCAP Erez spoke about Image inspector which is build on top of them and is utilized by OpenShift and ManageIQ to inspect container images. It is very good to see security getting nicely integrated into such tools and with the mentioned future work it will be even nicer to use.

For the last talk of today I joined Colin Charles from Percona who let us take part on “Lessons learned from database failures”. On his agenda were backups, replication and security. Without blaming and shaming Colin took many examples which failed and explained how it could be done better with current software and architecture. This remembers me to catch up on MySQL and MariaDB features before they hit enterprise distributions.

So this is it for today, after so many interesting talks I will have some food, drinks and conversation at the evening event taking place at Umspannwerk Ost. Tomorrow I will hand over the blog to Michael because I will give a talk about Foreman myself.

Dirk Götz

Autor: Dirk Götz

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Nagios, Puppet und andere Systems Management Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich.