Skip navigation
This discussion is archived

How to encrypt AFP sessions

5088 Views 8 Replies Latest reply: Jun 8, 2008 9:11 PM by rkovelman RSS
Peter Glock Calculating status...
Currently Being Moderated
May 28, 2008 2:25 AM
I want to improve the security of information being sent over our network, both internally and for internet connected users. For internet connected users I can set up VPN access reasonably easily but I am looking for a way to make a secure connection transparent for both external and internal users.

I have set up LDAP look-ups for shared address book to use authenticated SSL (and opened the relevant port on my firewall) so that it is now irrelevant to a user whether they are inside or outside the firewall when using the address book.

Under Tiger there is an option to encrypt AFP (using OpenSSL I believe) for both login and for file sharing. Under Leopard it seems that there is only encryption for login but not for file transfer so that anyone sniffing the local network can capture any file (I've tried this successfully using ettercap).

Is there any way to replicate the Tiger behaviour under Leopard?
Power Mac g5, MacBook Pro, 2 x iMac g5, g4 Quicksilver, mac minis, iBook G4..., Mac OS X (10.5.2), Infrant readyNAS 600 (2TB)
  • rkovelman Level 2 Level 2 (320 points)
    Currently Being Moderated
    Jun 3, 2008 7:14 AM (in response to Peter Glock)
    I would make sure under authentication you select Kerberos, kill users after they have been idle, make sure you have a valid cert, disable guest access.

    For SSL go here:

    Below is what that link states

    The Change

    The difference between 10.4 and 10.5 lies entirely in /etc/openldap/ldap.conf. Where before it used to say

    TLS_REQCERT = never
    now it says

    TLS_REQCERT = demand
    This change means that the underlying ldap client will only use SSL certificates that it thinks are valid dropping the connection attempt if it thinks the cert is bad. So, what constiutes a valid cert?

    Out of the box... nothing. The LDAP client trusts no one. Even if you actually paid for your SSL certificate and you have no issues when you use it to secure a website, the LDAP client will still refuse it. Annoyingly the GUI, in this case Directory Utility, will happily show you a green dot next to your server, it's just that it won't actually be used. If you require binding and SSL, that should fail as well.

    While this is annoying if you didn't expect it, I find it hard to argue that it was a bad move. Without validating a site against its own certificate left the client systems open to something as simple as a DNS poisoning attack. So I do feel that this is a good thing, but it cetainly does take a bit more work to get things functioning.

    Test via the CLI

    The easiest way to test what exactly is going on is to use the ldapsearch command to verify if you're able to connect or not. This assumes that you've first set up OD and enabled SSL for LDAP, either using the default certificate on the server or one you've configured yourself.
    ldapsearch -v -x -H ldaps:// -b "dc=biggie,dc=afp548,dc=com"
    Substituting in your correct server FQDN and search domain. This should fail on a stock 10.5 install with this error.
    ldap_bind: Can't contact LDAP server (-1)
    additional info: error:14090086:SSL routines:SSL3GET_SERVERCERTIFICATE:certificate verify failed
    Fairly self-explanatory, at least to what the error is. So now how to fix it.

    Get the Cert

    You're going to need to feed the cert to the LDAP client so that it knows to trust it. While it's possible to do this via exporting the cert from the server itself it's typically easier to use the "openssl s_client" to snarf the cert.
    openssl s_client -connect
    Which should come back with a deluge of information for you. Within that is going to be a dozen or more lines that are blocked off by:
    -----END CERTIFICATE-----
    Take that text, including the begin certificate and end certificate lines and paste them into a text file. A CLI text editor would be best for this to ensure that you don't accidentally save it as a .rtf or something funky like that.

    For purposes of demonstration we'll assume that you've saved the cert to /tmp/ssl.cert.

    Note: you should get an error number 18 or 19 when using the s_client. This refers to either a self-signed certificate, 18, or a self-signed certificate in the chain, 19. Keep this in mind as the next step should clear this out.

    BTW, control-c to get out of the s_client connection.

    Test the Cert

    Now that you have the cert sequestered into a text file you can test again with s_client manually specifying the certificate.
    openssl s_client -connect -CAfile /tmp/ssl.cert
    Which should display similar output to before, however, with a significant change to the last line:
    Verify return code: 0 (ok)
    Instead of either the 18 or 19 that you were getting before. This means that you've successfully managed to get openssl to be happy with the certificate that you're using on the remote server. So now to make LDAP as happy...

    Edit ldap.conf

    You are going to need to add a new line to /etc/openldap/ldap.conf that points to the certificate you've just pulled down. I tend to keep things tidy here and create a /etc/openldap/certs folder and then just copy the text file that we got before into there. Here we'll assume you renamed the file the name of the server and put it into this location.

    After moving the cert you can add one line into /etc/openldap/ldap.conf
    TLS_CACERT /etc/openldap/certs/
    Now retest with the ldapsearch command and see if it works.
    ldapsearch -v -x -H ldaps:// -b "dc=biggie,dc=afp548,dc=com"
    Should actually return an LDIF of your whole LDAP setup, so this may take a while. Trim down the search if you want.

    Ensuring OD Works

    At this point you should be able to join and use an SSL-secured OD setup via Directory Utility. So please do that at this time. You may need to kick Directory Services if you had already attempted to setup the LDAP server.
    sudo killall DirectoryService
    Securing a Collection of Certs

    The method above will only allow that one specific server, with that one specific cert to be trusted. If you have multiple LDAP servers you're working with you're going to need to specify those individually, or put them all in the same directory and point ldap.conf towards them. Here's how to do the later.

    Grab all of the certs as before using openssl s_client.
    Now you're going to have to use another OpenSSL utility to get the certs into a hashed format.For each cert you will run the it through c_hash which will give you a name that you'll need to rename the cert file to.
    /System/Library/OpenSSL/misc/c_hash /etc/openldap/certs/
    03be8eb2.0 => /etc/openldap/certs/
    In this example you'd rename your existing cert file to 03be8eb2.0

    Then you can add
    TLS_CACERTDIR /etc/openldap/certs/
    to your /etc/openldap/ldap.conf file.

    Probably best to remove any earlier TLS_CACERT directives you have in ldap.conf at this time as well.
    On the Other Hand

    You could revert the ldap.conf file back to the 10.4 behavior and be done with all this...


    Note that while it would certainly make most of the pain go away, OpenSSL and therefor the LDAP libraries have no concept of what a keychain is. So, no, importing the certs into your keychain won't do anything for the LDAP issue.

    Other Notes

    You will never be able to use the default certificate that comes with OS X Server without changing TLS_REQCERT back to never. The default certificate isn't configured with a hostname so it will never pass an integrity check.

    As mentioned by Mr. McCune in the comments, you may also want to investigate pointing ldap.conf to the default trusted root store that is included with curl on OS X.

    TLS_CACERT /usr/share/curl/curl-ca-bundle.crt
    Which should allow you to use a purchased certificate without having to do additionaly mods to ldap.conf.
    ACTC, ACHD, ACDT, ACPT, Mac OS X (10.4.11)
  • rkovelman Level 2 Level 2 (320 points)
    Currently Being Moderated
    Jun 6, 2008 7:09 AM (in response to Peter Glock)
    Well even a VPN connection is unsecure unless the server is plugged directly in to the VPN Appliance. Otherwise the traffic is still open. The only thing secure is the VPN connection from the mobile user to the VPN appliance. What I would suggest is doing SSL or SSH. Are you trying make certification or compliance? Just curious for why you need such a secure network...
    ACTC, ACHD, ACDT, ACPT, Mac OS X (10.4.11)
  • davidh Level 4 Level 4 (1,890 points)
    Currently Being Moderated
    Jun 6, 2008 11:53 AM (in response to Peter Glock)
    Well, you might go with an ssl-based VPN such as
    or use a dedicated hardware appliance such as the Zyxel SSL10 B9250FE96E7

    (SSL VPN functionality also in the higher-end Zywall 70 with IDP 510C6E1E708

    I gave the URL for their UK pages (they have US pages as well, possibly others...)
    Or of course, another vendor if you prefer.
  • rkovelman Level 2 Level 2 (320 points)
    Currently Being Moderated
    Jun 8, 2008 9:11 PM (in response to Peter Glock)
    I understand what your trying to accomplish but remember that any traffic before the VPN is not encrypted so as of right now your not secure in any way. Going beyond that depending on the VPN connection the data wont be plain text BUT might be easy to grab.

    Have you called Apple and asked about what your trying to do? There is an old Unix way I did it with NetaTalk found here:
    With this you can enable SSL over AFP.
    ACTC, ACHD, ACDT, ACPT, Mac OS X (10.4.11)


More Like This

  • Retrieving data ...

Bookmarked By (0)


  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.