My thoughts Just do it!

Gültiges selbstsigniertes Zertifikat erstellen

Ein gültiges Zertifikat zu erstellen ist keine Zauberei. Chrome (und ggf. auch andere Browser) prüfen die Zertifikate auf signifikante Attribute um eine größtmögliche Sicherheit zu gewährleisten.

In den neuen Versionen von Chrome werden Zertifikate mit einem Common-Name als ungültig betrachtet, wenn das Attribute subjectAltName nicht gesetzt ist (siehe auch https://support.google.com/chrome/a/answer/7391219?hl=de) und ein Aufruf wird mit der Meldung NET::ERR_CERT_COMMON_NAME_INVALID quitiert.

Damit dieses Problem nicht auftritt gibt es die Möglichkeit, ein Zertifikat mit diesem Attribut zu versehen, während man es via openssl erstellt. Unter anderem kann man eine recht komplexe Kommandoabfolge verwenden (Rezept):

openssl req \
-x509 \
-newkey rsa:4096 \
-reqexts SAN \
-config <(cat /etc/pki/tls/openssl.cnf \
<(printf "\n[SAN]\nsubjectAltName=DNS:domain.tld,DNS:site.domain.tld")) \
-keyout /etc/ssl/certs/site-key.pem \
-out /etc/ssl/certs/site-cert.pem \
-days 365 \
-nodes \
-subj "/C=DE/CN=site/O=site.domain.tld"

Dieses Kommando erstellt ein Zertifikat für die Domain site.domain.tld sowie dem Alternativnamen domain.tld via einer temporären Erweiterung. Der Parameter bereitet openssl darauf vor, die Erweiterung SAN aus der Konfiguration anzufordern. Da in der Datei /etc/pki/tls/openssl.conf (der Pfad ist für CentOS 6 gültig, andere Distributionen können variieren) eine solche Erweiterung bestimmt nicht konfiguriert ist, wird der Rest via Parameter -config eingefügt.

Die Schlüsselbittiefe ist ebenso an die eigenen Bedürfnisse anzupassen, wie die Domainnamen und Pfade.

Ich übernehme keine Verantwortung für etwaige Probleme mit der SSL-Konfiguration. Bitte kontrolliert auf jeden Fall eure Einstellung, bevor ihr diese Kommandos ausführen wollt.

 

Das erstellte Zertifikat kann beispielsweise in den Apache oder nginx eingebaut werden. Anschließend kann man das Zertifikat natürlich auch mit dem Browser herunterladen und in den eigenen CA-Storage hinzufügen, um ihm endgültig zu vertrauen.

Android Platform-Tools und Build-Tools auf CentOS 6.x

Der User Juloor hat im Post Einfach mal die Android-Build-Tools auf CentOS 6 fixen den Kommentar veröffentlicht, das die aktuellen Build- und Platform-Tools mit der originalen Anleitung nicht mehr zum Laufen zu bringen sind.

Ich hab das mal als sportliche Herausforderung angenommen, das Problem zu beheben.

Hier mein Vorgehen:

1. Installieren einer neueren Version der glibc

Ich hab nach einem kurzen Test festgestellt, dass die neueste Version 2.26 mit meinem aktuellen Platform-Compiler Gcc 4.4.7 nicht bauen wird.

Mit der mindest-angeforderten Version 2.15 hagelt es Segmentation Faults.

Daher bin ich zunächst auf die 2.20 geschwenkt und habe diese nach der o.g. Anleitung in /opt/glibc-2.20 installiert. Entpacken - ins neue Verzeichnis wechseln und einen Unterordner "build" erstellen, wieder hinein wechseln.

$ ../configure --prefix=/opt/glibc-2.20 && make && make install

2. Danach habe ich die Platform-Tools auf die aktuellste Version (rev 26) upgedated

$ cd /opt/android/tools
$ ./android update sdk --all --no-ui --filter 1,2,3 

Dabei wurden auch die Android SDK Tools auf Version 25.2.5 und die Android SDK Build-tools auf Version 26.0.1 angehoben.

3. Anschließend habe ich den "Patch" aus https://www.nkey.de/post/einfach-mal-die-android-build-tools-auf-centos-6-fixen/ wieder auf /opt/android/build-tools/26.0.1/aapt und zusätzlich auf /opt/android/platform-tools/adb angewendet, diesmal aber etwas am Shell-Script modifiziert

#!/bin/bash
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
/opt/glibc-2.20/lib/ld-linux-x86-64.so.2 --library-path /opt/glibc-2.20/lib:$LD_LIBRARY_PATH:/lib64 ${DIR}/adb.bin $*

Ausgaben:

$ /opt/android/platform-tools/adb version
Android Debug Bridge version 1.0.39 Revision 3db08f2c6889-android
Installed as /opt/glib-2.20/lib/ld-2.20.so
$ /opt/android/build-tools/26.0.1/aapt version
Android Asset Packaging Tool, v0.2-4187382

Einfach mal die Android-Build-Tools auf CentOS 6 fixen

EDIT: Wenn man die neuesten Build-Tools 25.2.5 sowie die Platform-Tools 26.0.1 laufen lassen will, funktioniert diese Anleitung nicht mehr. Bitte statt dessen den neuen Eintrag verwenden: https://www.nkey.de/post/android-platform-tools-und-build-tools-auf-centos-6-x/ 

 

Leider können die aktuellen Android SDK Build Tools (Version 25.0.2) auf CentOS 6 nicht out-of-the-box laufen. Man bekommt den Fehler

/lib64/libc.so.6: version `GLIBC_2.14' not found

 

Also erst mal die GLibC 2.14 installieren, Howto gibt es hier: http://www.imperx.com/wp-content/uploads/Member/Cameras/Bobcat_Gen2/GEV%20Linux/Workaround_to_install_GLIBC_2.14_to_CentOS_6.7.pdf

 

Danach muss man aapt "patchen". Ich bin dafür diesen Weg gegangen:

 

cd /opt/android/build-tools/25.0.2
mv aapt{,.bin}
cat > aapt.sh << EOF
#!/bin/bash
DIR="\$( cd "\$( dirname "\${BASH_SOURCE[0]}" )" && pwd )"
LD_LIBRARY_PATH=/opt/glibc-2.14/lib \${DIR}/aapt.bin \$*
EOF
chmod +x aapt.sh
ln -s aapt.sh aapt

 

Und schon funktioniert der Aufruf von /opt/android/build-tools/25.0.2/aapt:

/opt/android/build-tools/25.0.2/aapt version
Android Asset Packaging Tool, v0.2-3544217
Home