Apple MacOS Server and iOS don’t like StartCom Certificates

An error reading „Cannot Connect Using SSL“ on my iPhone caused me some extra grey hair: The symptoms I observed since mid of December were:

  • iOS Mail came up with a SSL error when trying to negotiate SSL/TLS through the IMAP service on my MacOS server. Adding a new mailbox was not possible, Apple Mail always suggested to turn of SSL (which I didn’t want to do for good reason).
  • My Squirrelmail webbased email reader suddenly couldn’t connect to the IMAP mailbox anymore. The error observed was: „Error connecting to IMAP server: <server_name>. 0

First I thought that there was a problem with the MacOS Server, but when I switched to a self signed certificate – things worked OK again (only with the hint that I use an untrusted cert of course).

After some more googling around for the symptoms I observed, I came across this article Lists of available trusted root certificates in iOS (in German). It clearly mentions, that from December 2016 onward, the certificates of StartCom (which were available also cost free) are not recognized anymore. Now, my MacOS Server did not throw any error in the Server Manager, but the services didn’t work as expected anymore.

And for testing Squirrelmail, I found this very nice information at James Bottomley’s random Pages:

echo 'fsockopen("tls://yourmailserver.domain",993,$errno,$errmsg,15);'|php -a

I used it to check the connection to my mailserver, and look and behold, I got to see the PHP error that I had a certificate issue!

So I decided to order a RapidSSL certificate to replace the StartCom certificate. Said and done, set it all up, and voilá – all services are running smoothly again.

While the Server App correctly changes certs for all services including the postfix Mail service, I have configured TLS manually in the postfix as this was a requirement for my outbound mail forwarder. These configuration statements I always have to change manually when updating the certificate. Now there is at the end of the file:

smtp_tls_cert_file = /etc/certificates/<hostname>.ID.cert.pem
smtp_tls_CAfile = /etc/certificates/<hostname>.ID.chain.pem
smtp_tls_key_file = /etc/certificates/<hostname>.ID.key.pem

For the correct keys just compare to the statements before, like:

smtpd_tls_key_file = /etc/certificates/<hostname>.ID.key.pem
smtpd_tls_cert_file = /etc/certificates/<hostname>.ID.cert.pem

If you run into similar troubles as described above, I suggest to get a „real“ SSL certificate which is trusted by the Apple OS. I got mine from the folks at

Dual Monitor Setup with Two Different Backgrounds in Windows 10

Ok, this is rather a gimmick, but this was the wish behind: I have a dual screen setup in my office. Normally, the same desktop wallpaper would be shown on both displays. Now I have a list of internal telephone numbers and wanted to display those only on one of the desktops. I created two different wallpaper images, one with the phone number list, the other without. This is the way how you can display two different images without any additional software:

  1. Copy the background images into the path: C:\Windows\Web\Wallpaper\Windows.
  2. Now use the CTRL key for multiple selection to select both backgrounds.
  3. Right click on one wallpaper image -> Choose „Set as desktop background“.

The selected wallpaper images will be stored under:
Transcoded_000 and Transcoded_001 without extension

If you want to swap the images, just rename 0 to 1, 1 to 0. Sign out and sign back in or right click on desktop and select: Next desktop background.

(This solution was originally published here.)

Substitute the failing Seagate Series ST3000DM001

I love my two Promise Pegasus R4 Thunderbolt Storage Shelters. Some months ago I upgraded the Backup Storage to 3TB drives, Seagate’s ST3000DM001. Unfortunately, as Backblaze reveals, this series is very buggy and not at all recommendable. So, whenever one of the drives had failed, I would substitute it with a Seagate ST4000DM000 drive, which is a 4TB model. Backblaze shows, that this model is quite ok when it comes to error statistics. What I always thought was, that Promise Pegasus R series would only support the drive models which can be found in the Pegasus Promise compatibility listing. But No! What drives can be used with Promise Pegasus R4, R6 or R8?

Then today, when another of Seagate’s 3TB drives failed, I looked for a substitute and came across the Seagate ST4000VN000 – which is listed as proper NAS drive. I was courageous and bought one from Cyberport and hoped it would fit and work in my Pegasus Promise R4. As you can see here:

Screen Shot 2016-08-06 at 21.52.55

The RAID is being rebuilt ...
The RAID is being rebuilt …

Thus I can say with confidence:

The Seagate NAS drive ST4000VN000-1H41, which is a typical SATA drive with 4TB capacity, runs well in the Promise Pegasus R series, even though it is not listed in the compatibility list. And I am still running on firmware release 5.04.0000.36. The benefit of this slightly more expensive hard disk is a 3 year warranty (within Germany) and – as Seagate claims – some extra routines to make it work 7×24.

Kyocera M6526cidn & Scan to Folder & SMB Shares on MacOS El Capitan Server

After Upgrading to El Capitan, my Kyocera MFC didn’t want to save scans via SMB connection anymore. This brought me to google wildly after any solution, and I came across these documents, which kept enlightening me:

As I had set up a user named „scanuser“ in the Mac OS Server App, I kept looking there, why it wouldn’t work. I changed permission rights and even switched the system back to SMB v1, by entering the following in a console window:

echo "[default]" >> ~/Library/Preferences/nsmb.conf; echo "smb_neg=smb1_only" >> ~/Library/Preferences/nsmb.conf

If you need to change it back, you just enter:

rm ~/Library/Preferences/nsmb.conf

But, to no avail!

So I looked into System Preferences and Users again and thought, I might create a local user called „scanuser“. This I did, and suddenly my Kyocera printer & scanner was willing to talk to the SMB share on my Mac OS Server again.

Traffic Attack from Baidu Address Space

Yesterday I noticed that one of my servers was seeing more traffic than usual. The hourly traffic limit I had set was reached and my mailbox filled with traffic warning messages. I wanted to look into the matter but wondered: how can I quickly see which IP connections exist? Fortunate to be on a Debian Linux, I decided to install the package iptraf. This IP LAN monitor generates various network statistics and showed me that most of the new connections came from one particular IP range: WHOIS DB shows, that this range belongs to BAIDU, the famous search enterprise in China. Generating several hundred Megabytes of traffic per hour was too much for me. You can see the traffic line here:

Graph showing the Baidu Traffic Attack
Start of the Baidu traffic phenomenon
Graph showing the Baidu Traffic Attack
Trying to counter the Baidu traffic phenomenon.

First of all I thought it might be the indexing work of many Baidu spiders, or of spiders claiming to be Baidu. In this regard, I found a very helpful post by the folks at Perishablepress, which explains how to block the Baidu spidering process through the .htaccess file.

This did not really solve the problem, so I took more serious measures and blocked the whole address space of Baidu via iptables Firewall. This is the command you need (please be root before using it):

iptables -A INPUT -s -j DROP

Just remember, that this statement really blocks all the traffic from the Baidu network. So if your servers are meant to reach Chinese visitors, you might want to think twice before you block it all!

Movable Type goes WordPress

Finally: Jahrelang lief auf meinem Root-Server bei IBH halb versteckt der Blog Äppeltexte auf einer Installation von Movable Type. Da es MT ja nicht mehr als OpenSource gibt, ist eine WordPress-Installation das naheliegendste. Daher heute Abend mal fix die Installation angeworfen, die wirklich supereinfach auf einem Debian GNU/Jessie durchzuführen ist. Dann half Google weiter, um etwas über die Migration von Movable Type zu WordPress nachzulesen. Ich empfehle den Beitrag Importing from Movable Type to WordPress. Jetzt freue ich mich, hier auf WordPress-Basis weiterbloggen zu können!

Diese Datei ist durch einen anderen Benutzer geöffnet …

In meiner gemischten Umgebung von Mac OS Systemen und ein oder zwei Windows Rechnern arbeiten wir u.a. mit einem Excel-Dokument, welches es immer wieder zu aktualisieren gilt. Das mache ich manchmal mit Excel auf einem Windows-System und manchmal mit dem Office auf meinem Mac. Zuletzt kam allerdings auf dem Mac immer die Fehlermeldung, dass diese XLSX-Datei von einem anderen Benutzer zur Bearbeitung gesperrt ist. Nach 3 Sekunden da man das Dokument offen hatte kam dann die Meldung, dass es jetzt frei geworden sei, und sobald man auswählte, dass man es nun zur Bearbeitung erneut öffnen möchte, kam wieder derselbe Fehler: Die XLS-Datei ist von einem anderen Benutzer geöffnet und gesperrt.

Hier die Lösung des Problems: Sehr wahrscheinlich gibt es in dem Verzeichnis, wo die Datei gespeichert ist, eine temporäre Datei die eigentlich automatisch hätte gelöscht werden müssen, was aber nicht passiert ist. Man kann sich wie folgt behelfen:
– Mac Terminal öffnen
– In das Verzeichnis wechseln, wo die Datei liegt (wenn es ein Netzlaufwerk ist findet man es, in dem man auf dem Mac zunächst cd /Volumes eingibt und dann z.B. auf das angeschlossene Promise Pegasus Laufwerk wechselt)
– Im Verzeichnis lässt man sich mit „ls -rtl“ alle Dateien anzeigen, einschliesslich der versteckten Dateien
– man wird fündig, denn es gibt Dateien die heißen z.B. „~$account-overview.xlsx“, beginnen also mit „~$“ und werden im Standard im Finder nicht angezeigt.
– mit „rm ~$*“ lassen sich sofort alle temporären Dateien löschen, oder löscht nur die eine, die gerade gestört war.
Soeben probiert: Danach lässt sich die Datei wieder problemlos im Mac Office / Excel öffnen und bearbeiten.

iPhone 4 and Exchange calendar entries marked private

I just switched to an iPhone 4. From my poor old Nokia E72. Well, that is a real change! Since I work heavily with my calendar in Outlook, I wondered how I can set up the iPhone to sync with Exchange. The setup worked pretty flawless, but then I noticed I couldn’t create calendar entries marked as „private“.

It has to do with the concept of the calendar system. With the old Exchange – Outlook connection, there was one calendar and I was able to mark personal entries as „private“ to hide them from my colleagues who are allowed to look into my calendar for making appointments. My Nokia with Symbian allowed this setting of a private marker too.

The iPhone as well as Android software (as far as I know) do not know a private mark. Rather it is possible to set up several calendars. I learned, that I can subscribe to certain calendars online – for instance to show the week of the year or to show sunrise and sunset. 

That brought me to have a closer look at my Outlook (version 2010 by the way) and the Exchange server behind it (an Exchange 2007 serveR). Thus I found out, that on our company’s Exchange server I can create additional calendars.

So what I did now is the following:

– I created another calendar in my Outlook (on the Exchange server), named „Private“, to which my colleagues do not have access
– My Outlook 2010 allows me to show the „public“ calendar and the private calendar as an overlay, so I see all entries in one window
– my iPhone syncs perfectly with both calendars – so whenever I need to create a private entry I just choose it to go to the Exchange calendar named „private“, whereas a public entry goes to the regular Exchange calendar.

In this way I am able to work fine with my iPhone’s calendar system. Just a bit time needed to get used to it! 🙂 So, no need for any add-on! In any case, all googleing only led to the conclusion that marking a calendar entry as private is not possible with the iCal, nor is there any third party software which would offer that function (not even the well known pocket informant nor other similar software).

Nokia E72 Kalender und Mail for Exchange Fehler 15006

Seit einigen Tagen fiel mir auf, dass mein Nokia E72 die Kalenderdaten nicht mehr mit dem Exchange Server 2007 synchronisiert. Ich erinnere mich an den letzten solchen Fall, als mir der Nokia Support die neue Firmware 031.023 (Custom Version für die Behebung des Fehlers zur Verfügung stellte. Da musste ich allerdings einen Factory Reset des E72 machen, was absolut keinen Spaß macht, da man hinterher alle Einstellungen und Programme neu installieren darf.

Auf folgendem Weg findet man Logfiles zu Mail for Exchange (MfE) im Nokia:

1. MfE -> Settings -> Mailbox (nicht Global Settings) -> Options -> View log
und die kompletten Logs
2. Office -> File Manager -> Phone Memory -> MailforExchange -> admin_log[1-3].txt

Hier die typische Fehlermeldung aus dem admin_log:

2010/09/21 08:58:09 Mail For Exchange Error -15006
2010/09/21 08:58:09 Error occurred during Ping.
2010/09/21 08:58:09 Exception during Ping.
2010/09/21 08:58:09 Mail For Exchange Error -15006
2010/09/21 09:01:25 PING Command Requested
2010/09/21 09:03:11 start Calendar sync
2010/09/21 09:03:11 status from server indicates a protocol error
2010/09/21 09:03:11 Nothing to sync
2010/09/21 09:03:11 end Calendar sync
2010/09/21 09:03:11 Mail For Exchange Error -15006

Diesmal habe ich wiederum Google bemüht und bin fündig geworden!

Eigenartigerweise befindet sich unter den ersten Suchergebnissen eine Nokia-Seite aus Lateinamerika, deren Patch aber tatsächlich Abhilfe schafft:

Die Symptome werden dort wie folgt beschrieben:

Mail For Exchange Error -15006

Customers that are running MfE on E72 with firmware 31.023 may see the following symptoms and errors:
Unable to sync E72 devices with Exchange Servers
MfE Contacts stop syncing
Calendar Sync Issues
Mail For Exchange Error -15006 in Admin Log files
Exchange Server 2003 Contact issues
Exchange Server 2007 Calendar issues
Device E72
Firmware 31.023
Steps for installing the patch are in a readme file in the file
Patch file for E72 Mail For Exchange Error -15006

Ich habe diesen Patch in der in der Readme beschriebenen Form angewendet (Erst Exchange Postfach entfernen, dann neu starten, dann Patch installieren, dann noch mal neu starten, dann Postfach wieder neu anlegen), und momentan synchronisieren die Kalendereinträge wieder wie gewohnt.

Interessant war bei der Installation noch, dass sich der Patch mit derselben Version meldet, wie das bereits installierte MfE. Dennoch scheint es eine gepatchte Version zu sein, denn bei den Mail-Einstellungen unter „When to sync“ gibt es jetzt eine Einstellung für „Heartbeat interval“ (Standard bei 11) und im Logfile gibt es (die habe ich vorher m. E.  nicht gesehen) eine Datei namens pdu_log.txt.

Ich hoffe, diese Informationen helfen anderen vom Kalender-Sync Ausfall „Betroffenen“ weiter.