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.

This problem was been resolved. The ASUS "Dark Knight" router which was providing the private LAN (NAT) and port forwarding to the Mac running OS X Server has a firmware bug. The bug manifest by DROPPING the ESTABLISHED TCP connection on port 2195 between the Mac running OS X Server and APNS, after two hours of quiescence. The router should not have dropped this connection, there was no firewall rule instructing it to do so. The lesson learned is to be much more selective and wise with regard to choosing routers (especially consumer off-the-shelf variety) for use with servers even for servers run in a small business context (like a Mac Mini Server).

Heading