Need help starting the slapd daemon

[astyle]

Discussion: My original problem is that git doesn't like self-signed certificates. I managed to set up a basic git repo on localhost that is served up via this URL: https://git.beastie.localdomain/freebsd_kde/ports.git/. I can use firefox to browse the repo no problem. Trouble arises when I try to feed that URL to git - it complains about a self-signed cert and refuses to clone the repo.

That prompted me to study how certs are generated, how they are even supposed to work, and how to string options together to produce a valid cert. openssl(1) was somewhat helpful in translating info off the Internet to my scenario. But I'm still lost in the details. I tried reading the Handbook section on OpenSSL, and it says that

If a certificate has not been signed by an external Certificate Authority (CA), such as http://www.verisign.com, the application that uses the certificate will produce a warning.

Well, git refuses to do anything!

One solution that I've been pointed to is to use Let's Encrypt!, a public service. Thing is, there's a different option I'd rather do: the Handbook section on OpenSSL says that you can be your own CA:

Refer to “Configuring an LDAP Server” for an example of how to create a CA for signing one’s own certificates.

This actually looks like something that will solve the complaints from git... so I followed along, starting at Section 30.5.2, Configuring an LDAP Server. I seem to have gotten past the openssl commands OK:

root@beastie:/usr/local/etc/openldap # ls -l *.crt
-rw-r--r--  1 root  wheel  1468 Jan 28 17:23 ca.crt
-rw-r--r--  1 root  wheel  1338 Jan 28 19:12 signed_client.crt
-rw-r--r--  1 root  wheel  1224 Jan 28 17:41 signed_server.crt
root@beastie:/usr/local/etc/openldap # ls -l private/
total 27
-rw-------  1 root  wheel  1704 Jan 28 17:20 ca.key
-rw-r--r--  1 root  wheel  1062 Jan 28 17:47 client.csr
-rw-------  1 root  wheel  1704 Jan 28 17:44 client.key
-rw-------  1 root  wheel  1708 Jan 28 17:31 private_server.key
-rwx------  1 root  wheel   524 Jan 27 17:06 san.conf
-rw-r--r--  1 root  wheel  1106 Jan 28 17:32 server.csr

Question:

Trouble seems to start when I edit the /usr/local/etc/openldap/slapd.ldif config file. I thought I edited the file properly, following the syntax, and used slappasswd(8) when the Handbook told me to. But, running /usr/local/sbin/slapadd gave me an error. It is captured in the attached typescript file. I tried to proceed to the next step as per the Handbook, starting the daemon. No go, so I tried to start it with debugging info: /usr/local/libexec/slapd -F /usr/local/etc/openldap/slapd.d/ -d 5, and captured the output into the same typescript file. I'm also attaching the slapd.ldif file - Is something up with the file, or is my problem elsewhere?

Any help or insight would be greatly appreciated!

 

[astyle]

Makes me wonder... do I even need to start the LDAP/slapd daemon to be my own CA in order to have valid certs to give out to likes of git? Or should I be looking at something else, like certctl(8)? I'd like to be able to connect the dots.

 

[astyle]

Finally solved the original problem myself:

# git config --global http.sslCAINFO /usr/local/etc/apache24/server.crt
# git clone https://git.beastie.localdomain/freebsd_kde/.git
Cloning into 'freebsd_kde'...
Fetching objects: 174878, done.
Updating files: 100% (139130/139130), done.

git config told git to globally use my original server.crt cert file - yeah, that's what I want.
git clone only took the URL as specified above - I wanted to use the URL that ends in ports.git, rather than just .git - no go.

I'm still interested in a clean setup of my own Certification Authority server and LDAP server, so if anyone has anything to add to this thread, that would be awesome!

 

[sidetone]

I believe that the CA needs to be on a different server or different location IP than where you're using the encrypted service to prevent man in the middle attacks. Once a good encrypted connection is established, it can't be broken into. The problem is that that connection can be spoofed at the begining to become an encrypted unbreakable connection to the unintended/spoofed connection. This has to do with self-signed certificates. Three points, one being the CA looking over the handshake, is exponentially harder and rare for a unwanted party to spoof against.

You asked about CA for use with git, though there's also DNSSEC, MonkeySphere and using manual fingerprints to ensure connections to the correct party. I'm not certain how DNSSEC works. security/monkeysphere is its own chain of public certification. https://blog.prosody.im/mandatory-encryption-on-xmpp-starts-today/ is about XMPP, but that's where I first learned about MonkeySphere and how DNSSEC could serve the purpose.

A cheesy joke: The CA needs to be in CAnada or CAlifornia.