<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
	<channel>
		<title>Sysadmin Blog</title>
		<link>https://www.cyberbyte.ch/blog/index.php</link>
		<description><![CDATA[Copyright Cyberbyte Networks]]></description>
		<copyright>Copyright 2026, Mike Rhyner</copyright>
		<managingEditor>info@cyberbyte.ch (Mike Rhyner)</managingEditor>
		<language>en-US</language>
		<generator>SPHPBLOG 0.8.1</generator>
		<item>
			<title>Reverse Proxy mit HTTP Auth im Backend</title>
			<link>https://www.cyberbyte.ch/blog/index.php?entry=entry170505-152715</link>
			<description><![CDATA[Damit man über einen Reverse-Proxy auf einen Web-Server zugreifen kann, welcher seinerseits wieder mit HTTP Basic Authentifizierung geschützt ist (und im Backend andere Login-Informationen als für die Anmeldung am Reverse Proxy erforderlich sind), muss die HTTP-Authentifizierung für den Backend-Server im Proxy-Abschnitt mitgegeben werden.<br /><br />Dazu muss zuerst Benutzername und Passwort in eine Base64-Zeichenkette encodiert werden:<br /><pre>echo -n &quot;User:Pass&quot; | base64<br />VXNlcjpQYXNz<br /></pre>(auch wenn kein Benutzername benutzt wird, muss das Doppelpunkt im zu encodierenden String enthalten sein!)<br /><br />Danach in der Konfiguration des als Reverse-Proxy verwendeten Frontend-Servers folgendes z.B. in einen Location-Abschnitt hinzufügen.<br /><br />Apache:<br /><pre>RequestHeader set Authorization &quot;Basic VXNlcjpQYXNz&quot;</pre><br />Nginx:<br /><pre>proxy_set_header Authorization &quot;Basic VXNlcjpQYXNz&quot;;</pre><br /><br /><strong>Technischer Hintergrund:</strong><br /><br />Sofern dieselben Anmelde-Informationen im Backend verwendet werden  wie im Frontend (Reverse-Proxy), sollte dieses bei der nachfolgenden HTTP-Auth Anfrage transparent vom Client Web-Browser weitergereicht werden, und obiger Parameter ist nicht notwendig.<br /><br />Wird hingegen versucht, sich mit unterschiedlichen HTTP-Auth Passwörter anzumelden (zuerst dasjenige für den Reverse-Proxy, dann dasjenige, welches der Backend-Webserver verlangt), ist darauf sofort die Anmeldung am Proxy nicht mehr gültig -&gt; Ein Zugriff würde so also nie funktionieren!]]></description>
			<category>General, Knowledge, Apache Stuff, Linux Stuff, Nginx</category>
			<guid isPermaLink="true">https://www.cyberbyte.ch/blog/index.php?entry=entry170505-152715</guid>
			<author>info@cyberbyte.ch (Mike Rhyner)</author>
			<pubDate>Fri, 05 May 2017 13:27:15 GMT</pubDate>
			<comments>https://www.cyberbyte.ch/blog/comments.php?y=17&amp;m=05&amp;entry=entry170505-152715</comments>
		</item>
		<item>
			<title>Turning SSLv3 off on Apache Server to mitigate &quot;POODLE&quot; attack (CVE-2014-3566)</title>
			<link>https://www.cyberbyte.ch/blog/index.php?entry=entry141016-102212</link>
			<description><![CDATA[Add the following to your SSL configuration section:<br /><pre><br />   # Disable SSLv2 &amp; SSLv3 against POODLE issue (CVE-2014-3566)<br />    SSLProtocol All -SSLv2 -SSLv3<br /></pre><br />Note to insert this to <strong>all</strong> VirtualHost sections where SSL is enabled!<br /><br />Check your config:<br /><pre>apachectl configtest<br /></pre><br />Then restart apache server:<br /><pre>sudo service apache2 restart<br /></pre><br />To check if SSLv3 is turned off:<br /><pre>openssl s_client -connect <a href="http://www.ownspace.ch:443" >server.domain.tld:443</a> -ssl3<br /></pre><br />Then you shold see a message like this:<br /><pre>error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1260:SSL alert number 40<br /></pre><br />To disable SSLv3 within other services:<br /><a href="http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566" >see this post</a>]]></description>
			<category>Apache Stuff, OpenSSL</category>
			<guid isPermaLink="true">https://www.cyberbyte.ch/blog/index.php?entry=entry141016-102212</guid>
			<author>info@cyberbyte.ch (Mike Rhyner)</author>
			<pubDate>Thu, 16 Oct 2014 08:22:12 GMT</pubDate>
			<comments>https://www.cyberbyte.ch/blog/comments.php?y=14&amp;m=10&amp;entry=entry141016-102212</comments>
		</item>
		<item>
			<title>Create Private Key, Certificate Request and (optionally) self-signed cert using OpenSSL</title>
			<link>https://www.cyberbyte.ch/blog/index.php?entry=entry130211-200006</link>
			<description><![CDATA[First, set the common name (CN, ~FQDN) for the certificate:<br /><pre>CN=host.domain.tld</pre><br />Change to the directory where you would like to store the data relevant for certificates, e.g.:<br /><pre>cd /etc/ssl</pre><br />Then create a private key:<br /><pre>openssl genrsa -out private/${CN}.key 2048</pre><br />Generate the signing Request, either: <br />a) interactively, you&#039;ll have to answer some questions...:<br /><pre>openssl req -new -key private/${CN}.key -out ${CN}.csr</pre><br />b) using a customized openssl config file:<br /><pre>openssl req -new -config ${CN}-openssl.cnf -key private/${CN}.key -out ${CN}.csr</pre><br />Now you may either:<br />a) send the certificate request to an (official or internal) Certificate Authority to sign the Certificate<br /><br />b) for testing purposes only, you can also self-sign the certificate:<br /><pre>openssl x509 -req -days 1825 -in ${CN}.csr -signkey private/${CN}.key -out certs/${CN}.crt</pre><br />When you have received signed (or self-signed) certificate, you can copy all the files to the appropriate location.<br /><br />Probably you have to create a combined pkcs#12 (.p12, .pfx) file, containing private key and certificates:<br /><pre>openssl pkcs12 -export -in ${CN}.crt -certfile cafile.pem -inkey ${CN}.key -out ${CN}.pfx</pre>(where cafile.pem is the ca certificate bundle of issuing certificate authority)<br /><br />Clear the shell variable for the Common Name:<br /><pre>CN=</pre>]]></description>
			<category>Apache Stuff, OpenSSL</category>
			<guid isPermaLink="true">https://www.cyberbyte.ch/blog/index.php?entry=entry130211-200006</guid>
			<author>info@cyberbyte.ch (Mike Rhyner)</author>
			<pubDate>Mon, 11 Feb 2013 19:00:06 GMT</pubDate>
			<comments>https://www.cyberbyte.ch/blog/comments.php?y=13&amp;m=02&amp;entry=entry130211-200006</comments>
		</item>
		<item>
			<title>Remove Apache VirtualHost section</title>
			<link>https://www.cyberbyte.ch/blog/index.php?entry=entry120717-000000</link>
			<description><![CDATA[This small <a href="http://www.cyberbyte.ch/Linux/Apache/remove_virtual.pl" >perl script</a> removes a VirtualHost configuration section<br /><br />Call with:<br /><pre>remove_virtual.pl &lt;webname&gt; &lt;apache conf file&gt;</pre><br /><code>&lt;webname&gt;</code> is to be replaced with the FQDN of the name based virtual host (ServerName)<br /><br /><code>&lt;apache conf file&gt;</code> is the full path to the apache configuration file that contains the VirtualHost]]></description>
			<category>Tools &amp; more, Apache Stuff</category>
			<guid isPermaLink="true">https://www.cyberbyte.ch/blog/index.php?entry=entry120717-000000</guid>
			<author>info@cyberbyte.ch (Mike Rhyner)</author>
			<pubDate>Mon, 16 Jul 2012 22:00:00 GMT</pubDate>
			<comments>https://www.cyberbyte.ch/blog/comments.php?y=12&amp;m=07&amp;entry=entry120717-000000</comments>
		</item>
	</channel>
</rss>
