MacOS – How to start the docker daemon on macOS

I'd recommend creating another self-signed cert in Server.app that you can use for securing services (if the others were expired/deleted). By creating the certificate using Server.app, it will automatically be available for other services (like Open Directory).

After you've created a new self-signed certificate, follow steps 6 through 12 in this article (which describe how your SSL certificate can be configured for use with Open Directory). Performing the Open Directory -> Settings -> LDAP -> SSL configuration through Server Admin will write the correct certificate paths into the slapd config file.

Once you've corrected the certificate problems, Open Directory (slapd) should start normally (without you having to start it by hand). If Password Server still doesn't show running after that, you might try a reboot (or check to see if it's generating crash logs or other errors in Console.)

Edit

After modifying the certificate configuration for use with LDAP, it's probably worth checking to see that the machine has provided updated certificate paths to slapd in the slapd_macosxserver.conf file. That is, the unique string of numbers and characters in the key/cert paths should have changed.

To confirm that slapd can access the corresponding private key for the certificate that you're securing LDAP services with, you can check the file at /etc/openldap/slapd_macosxserver.conf...Look for a line mentioning certadmin...That line specifies the command that slapd is using to retrieve the private key from the Keychain. It's possible to perform that command (copy and paste) in Terminal to see if the private key passphrase can be retrieved:

/usr/sbin/certadmin --get-private-key-passphrase /etc/certificates/domain.com.456DACFFC771F8EB2F5A8E0EBB269969B8164097.key.pem

Once you've retrieved the passphrase, see if you can view the private key using that passphrase:

sudo openssl rsa -in /etc/certificates/domain.com.456DACFFC771F8EB2F5A8E0EBB269969B8164097.key.pem -text -noout

When prompted for the pass phrase, copy and paste the value that you obtained in the step above. You should see the private key data output on the screen. This would confirm that:

1.) Your private key passphrase can be retrieved from the Keychain

2.) The pass phrase in the Keychain can be used to decrypt the key

If you are unable to get the pass phrase and unlock the key, it's possible that slapd is not able to either. I believe that the software is using a keychain item in the System keychain named "Mac OS X Server certificate management" with a kind of "application password". The "Account" for that keychain item should be set to the same unique string of characters and numbers (456DACFFC771F8EB2F5A8E0EBB269969B8164097 in this example) that you see in the cert/key paths in /etc/certificates. If you do not see one of these corresponding application passwords in the System keychain, it may be your issue.

The service is used for delivering you push notifications. Push notifications usually appear in the Notification Center in the top right corner of your desktop. Read more about it here:

http://support.apple.com/kb/ht5362

If you disable the service, you'll probably lose notifications for events such as received iMessage-messages, Facetime calls and notification from websites that you have requested notifications from.

From what you write, there does not seem to be a weighty reason for disabling it. It is a normal, system service that should not pose a problem to your system.

The connections in FIN_WAIT_1 state does not pose a problem to your system. You can safely ignore it (in those numbers).

You can also safely ignore the log message. The log message does not indicate that there has been a "data leak" as such.

The reason for the log message is that Apple uses a large number of servers for sending your push notifications. Your computer will connect to a (somewhat) random of those servers. The server will present a generic certificate for the service, and not one customized to the exact "sub-server" you have connected to. That is the cause of the log message. This is something Apple needs to fix on their servers, but it is a known bug and not something you yourself can do anything about.

This does not mean that you lose encryption or anything like that, but it might mean that your system could be vulnerable to a Man-In-The-Middle attack, where you could be sent falsified Push Notifications. Whether that is indeed the case would require further research. It is most likely that Apple employed some sort of certificate pinning or similar to avoid this type of exploit. The likelihood that you should be attacked this way is pretty low anyhow. I.e. don't worry about it.

I don't see why you say the daemon is "misbehaving". It is not misbehaving more on your computer than on any other computer. You could say that it is misbehaving, but it is doing so by Apple's design. So instead, create bug reports with Apple to let them know that you're seeing a problem.

Of course, if you do not actually use Push Notifications for anything, you can safely disable it.