Chrome, certificates and missing_subjectAltNames Part 2 of 1

von Tim Albert | Jun 7, 2017 | Security, Linux

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

Senior Systems Engineer

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. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. 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...

Lies mehr von Tim und triff unser Team

Chrome, certificates and missing_subjectAltNames

von Tim Albert | Mai 24, 2017 | Windows, Betriebssysteme, Security

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

Senior Systems Engineer

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. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. 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...

Lies mehr von Tim und triff unser Team

Icinga 2 Best Practice Teil 5: Autosign von Zertifikatsanfragen in verteilten Umgebungen

von Lennart Betz | Mai 5, 2017 | Icinga

Ein jeder kennt das Problem, im Unternehmensnetz gibt es unterschiedliche netzwerkbezogene Sicherheitszonen, die mittels Perimeter voneinander getrennt sind. Für das Monitoring bedeutet dies im Idealfall, man stellt in jeder dieser Zonen einen Icinga-Satelliten bereit, der die von ihm ermittelten Ergebnisse an eine zentrale Instanz weiter meldet, den Icinga-Master. Damit ist gewährleistet, was Firewall-Admins berechtigterweise verlangen, lediglich Punkt-zu-Punkt-Verbindungen zu erlauben. Auch die Richtung des Verbindungsaufbaus ist mit Icinga 2 wählbar.
Setzt man zusätzlich auch Icinga 2 in der Ausprägung Agent ein, benötigt dieser ein signiertes Zertifikat um mit seinem jeweiligen Satelliten oder direkt mit dem Master zu kommunizieren. Im letzten Fall entstehen hieraus keine Probleme. In der Regel wird die CA, in einer Umgebung mit mehreren Satelliten auf dem Master betrieben. Bei lediglich einem Satelliten könnte die CA auch auf genau diesem Satelliten laufen, was jedoch Sicherheitsbedenken hervorruft. Ein Zertifikat aus einer niedrigen Sicherheitszone könnte verwendet werden, um mit einer höheren zu kommunizieren. Gleiches gilt natürlich auch bei der Benutzung lediglich einer CA, aber die Netzwerksicherheit soll ja dieses Risiko Minimieren.
Bleibt das Problem auf einem neuinstallierten Agenten mittels Autosigning ein beglaubigtes Zertifikat zu erhalten. Hier kann eine eigene CA auf jedem Satelliten Abhilfe schaffen. Der jeweilige Agent benötigt nun nur eine Verbindung zu seinem Satelliten um einen Request zu senden und keine Kommunikation zum Master. Wie wird nun dieses genau bewerkstelligt?

Erstellen einer CA auf dem Satelliten
Der Satellit bekommt ein Zertifikat signiert von seiner eigene CA
Der Satellit benötigt sein eigenes RootCA-Zertifikat und das vom Master
Der Master bekommt umgekehrt ebenfalls das RootCA vom Satelliten

Lennart Betz

Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Lies mehr von Lennart und triff unser Team