[CalendarServer-users] Configuring SSL with CA certs
Pascal Dallaire
pascaldallaire at cre-gim.net
Fri Feb 14 13:52:51 PST 2014
Hello there to mr LaBranche and the list,
I would like to thank you for this document, it was indeed a chain of certificate I needed, now I can have it work encrypted everywhere… next thing to learn is how to upgrade from 4.2 to 5.x without loosing too much stuff :)
Thanks again! Keep up the good work
Pascal
Le 2014-02-10 à 13:57, Andre LaBranche <dre at apple.com> a écrit :
> Hi,
>
> I don't immediately know what the problem is in your case, but here's a document I wrote some time ago about ssl cert chains and calendar server - maybe even during 10.6:
>
> Background
>
> Traditionally, a server's SSL certificate is signed by a well-known (root) certificate authority (CA). The signing CA is trusted (or not) by a client when the client consults the list of trusted root CA certs that is provided by Apple in every copy of Mac OS X. These trusted roots live in
>
> /System/Library/Keychains/SystemRootCertificates.keychain
> For a server using a SSL cert that is signed by a known authority, use of that cert is fairly straightforward: you provide the service the cert file and the corresponding private key file; when the client connects, the cert is validated against the client's list of trusted roots. It looks something like this:
>
> Root CA | << trust evaluation >> [client's list of trusted roots]
> |
> \
> Server cert
> In this configuration, the iCal Server config would contain something like shown below.
>
>
> <!-- Public key -->
> <key>SSLCertificate</key>
> <string>foo.com.crt</string>
> <!-- Private key -->
> <key>SSLPrivateKey</key>
> <string>foo.com.key</string>
>
> But then...
>
> For security reasons, CAs have recently begun to sign customer SSL certificates not with their root CA, but rather with an intermediate CA. An intermediate CA has a cert that was signed by the root CA. When the client tries to validate the server's cert, it checks to see that the signer (the intermediate CA) is trusted. This may be a problem, because the (newfangled) intermediate CA is typically NOT in the list of the client's trusted roots. This causes the client to throw warnings when connecting to the service over SSL.
>
>
> Root CA |
> |
> \
> Intermediate CA | << trust evaluation >> [client's list of trusted roots]
> |
> \
> Server cert
>
> What Now?
>
> Depends on who you ask. SSL is a rat's nest. For us (iCal Server), this means:
>
>
> Create an SSL Authority Chain file. This file specifies each step in the SSL authority chain, from the root down to the server cert. A graphical depiction of such a chain is shown in the previous section.
> Configure iCal server with an additional parameter that declares the location of the SSL Authority Chain file you created above.
> Constructing an SSLAuthorityChain file
>
> The SSL authority chain file is literally a concatenation of the server cert, any intermediate cert, and then the root cert. Be sure to specify them in the correct order based on the trust hierarchy. The server cert should be the first cert in the file, and the root should be the last. Each of these certificates should be made available by the cert provider. A concatenated chain file might look something like:
>
> -----BEGIN CERTIFICATE-----
> MIIFTjCCBDagAwIBAgIFArzGF0MwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYT
> AlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQHEwpTY290dHNkYWxlMRowGAYD
> VQQKExFHb0RhZGR5LmNvbSwgSW5jLjEzMDEGA1UECxMqaHR0cDovL2NlcnRpZmlj
> YXRlcy5nb2RhZGR5LmNvbS9yZXBvc2l0b3J5MTAwLgYDVQQDEydHbyBEYWRkeSBT
> ZWN1cmUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxETAPBgNVBAUTCDA3OTY5Mjg3
> MB4XDTA5MDQwMjE5MDU1N1oXDTEwMDMyNDIwMTczN1owPTEhMB8GA1UECwwYRG9t
> YWluIENvbnRyb2wgVmFsaWRhdGVkMRgwFgYDVQQDDA9zYWdlbi5hcHBsZS5jb20w
> ggEmMA0GCSqGSIb3DQEBAQUAA4IBEwAwggEOAoIBAQCizqn8jXCu3etpiCgO2EK0
> iBp+ka5uko9PxCe3ErdxJAxiICpZoJ4yzr1/7YBw4g9uznGztQYMzLCemEfU0Zku
> yOBY2wdROv5M8+/QncE7lMHxWD0PeKGPw8hzNwz6d9K19+DcYWP/gS/Ejwym8tSs
> WcTORqqJfLNeiH8UVBPExF8MnJZBOrVzQs6cWS0wn0/1JVL9hA6MACyY0X5LFcPB
> x8nZKZI5nvoCqZAs5CWJHf7oLJG8qTpDH4UnJnStp49FK8w1Z9y8XnujgrSVtnpE
> GhkAAmAq4LLYJJrwME4kSilHaLrAIsbNPe9IdPeGEdKeHlzo8hespHmebt/xwOdZ
> AgcBAAEAAQABo4IBwTCCAb0wDwYDVR0TAQH/BAUwAwEBADAdBgNVHSUEFjAUBggr
> BgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0PAQH/BAQDAgWgMDIGA1UdHwQrMCkwJ6Al
> oCOGIWh0dHA6Ly9jcmwuZ29kYWRkeS5jb20vZ2RzMS0zLmNybDBTBgNVHSAETDBK
> MEgGC2CGSAGG/W0BBxcBMDkwNwYIKwYBBQUHAgEWK2h0dHA6Ly9jZXJ0aWZpY2F0
> ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS8wgYAGCCsGAQUFBwEBBHQwcjAkBggr
> BgEFBQcwAYYYaHR0cDovL29jc3AuZ29kYWRkeS5jb20vMEoGCCsGAQUFBzAChj5o
> dHRwOi8vY2VydGlmaWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvZ2RfaW50
> ZXJtZWRpYXRlLmNydDAfBgNVHSMEGDAWgBT9rGEyk2xF1uLuhV+auud2mWjM5zAv
> BgNVHREEKDAmgg9zYWdlbi5hcHBsZS5jb22CE3d3dy5zYWdlbi5hcHBsZS5jb20w
> HQYDVR0OBBYEFE29F4wllnd5DUwh/XOkM4k71D3uMA0GCSqGSIb3DQEBBQUAA4IB
> AQAeHt2N7bHjph/sdtCxE1PhYwWSbxynsMGotpCAiJ1zYYbGlQR4l8uKZusbF8VU
> BBcf6VIMqODbCQopzXtzlxvyNPiVWKnWLyHidqXuoAN5oe6qznUDgtxt1kZ/Lduc
> +DkFwfsk4mix2EH0ExTPxXpVg0+ML8janhkBlzk4c3vH619hJRvnkVRypH9lL7m/
> mM6Ln69n/IWtzWxTC+tHDJ9iqxaG2Eym2apaXdrFNDTLWD08zsO/8DpPnQ3BvG0d
> VFxEvQP/goJcKtH/bxUkYqjpHOZirq+6wmXSN6l1SFdXyxwI2ih9GIY6VFDYuxyT
> mn1MH/O+DVYluXyCO2OaF07X
> -----END CERTIFICATE-----
> -----BEGIN CERTIFICATE-----
> MIIE3jCCA8agAwIBAgICAwEwDQYJKoZIhvcNAQEFBQAwYzELMAkGA1UEBhMCVVMx
> ITAfBgNVBAoTGFRoZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28g
> RGFkZHkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjExMTYw
> MTU0MzdaFw0yNjExMTYwMTU0MzdaMIHKMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH
> QXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UEChMRR29EYWRkeS5j
> b20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5j
> b20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2VjdXJlIENlcnRpZmlj
> YXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzCCASIwDQYJKoZIhvcN
> AQEBBQADggEPADCCAQoCggEBAMQt1RWMnCZM7DI161+4WQFapmGBWTtwY6vj3D3H
> KrjJM9N55DrtPDAjhI6zMBS2sofDPZVUBJ7fmd0LJR4h3mUpfjWoqVTr9vcyOdQm
> VZWt7/v+WIbXnvQAjYwqDL1CBM6nPwT27oDyqu9SoWlm2r4arV3aLGbqGmu75RpR
> SgAvSMeYddi5Kcju+GZtCpyz8/x4fKL4o/K1w/O5epHBp+YlLpyo7RJlbmr2EkRT
> cDCVw5wrWCs9CHRK8r5RsL+H0EwnWGu1NcWdrxcx+AuP7q2BNgWJCJjPOq8lh8BJ
> 6qf9Z/dFjpfMFDniNoW1fho3/Rb2cRGadDAW/hOUoz+EDU8CAwEAAaOCATIwggEu
> MB0GA1UdDgQWBBT9rGEyk2xF1uLuhV+auud2mWjM5zAfBgNVHSMEGDAWgBTSxLDS
> kdRMEXGzYcs9of7dqGrU4zASBgNVHRMBAf8ECDAGAQH/AgEAMDMGCCsGAQUFBwEB
> BCcwJTAjBggrBgEFBQcwAYYXaHR0cDovL29jc3AuZ29kYWRkeS5jb20wRgYDVR0f
> BD8wPTA7oDmgN4Y1aHR0cDovL2NlcnRpZmljYXRlcy5nb2RhZGR5LmNvbS9yZXBv
> c2l0b3J5L2dkcm9vdC5jcmwwSwYDVR0gBEQwQjBABgRVHSAAMDgwNgYIKwYBBQUH
> AgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTAO
> BgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBANKGwOy9+aG2Z+5mC6IG
> OgRQjhVyrEp0lVPLN8tESe8HkGsz2ZbwlFalEzAFPIUyIXvJxwqoJKSQ3kbTJSMU
> A2fCENZvD117esyfxVgqwcSeIaha86ykRvOe5GPLL5CkKSkB2XIsKd83ASe8T+5o
> 0yGPwLPk9Qnt0hCqU7S+8MxZC9Y7lhyVJEnfzuz9p0iRFEUOOjZv2kWzRaJBydTX
> RE4+uXR21aITVSzGh6O1mawGhId/dQb8vxRMDsxuxN89txJx9OjxUUAiKEngHUuH
> qDTMBqLdElrRhjZkAzVvb3du6/KFUJheqwNTrZEjYx8WnM25sgVjOuH0aBsXBTWV
> U+4=
> -----END CERTIFICATE-----
> -----BEGIN CERTIFICATE-----
> MIIEADCCAuigAwIBAgIBADANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJVUzEh
> MB8GA1UEChMYVGhlIEdvIERhZGR5IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBE
> YWRkeSBDbGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA0MDYyOTE3
> MDYyMFoXDTM0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRo
> ZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3Mg
> MiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN
> ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCA
> PVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6w
> wdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLOtXi
> EqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMY
> avx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+
> YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjgcAwgb0wHQYDVR0OBBYEFNLE
> sNKR1EwRcbNhyz2h/t2oatTjMIGNBgNVHSMEgYUwgYKAFNLEsNKR1EwRcbNhyz2h
> /t2oatTjoWekZTBjMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYVGhlIEdvIERhZGR5
> IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBEYWRkeSBDbGFzcyAyIENlcnRpZmlj
> YXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD
> ggEBADJL87LKPpH8EsahB4yOd6AzBhRckB4Y9wimPQoZ+YeAEW5p5JYXMP80kWNy
> OO7MHAGjHZQopDH2esRU1/blMVgDoszOYtuURXO1v0XJJLXVggKtI3lpjbi2Tc7P
> TMozI+gciKqdi0FuFskg5YmezTvacPd+mSYgFFQlq25zheabIZ0KbIIOqPjCDPoQ
> HmyW74cNxA9hi63ugyuV+I6ShHI56yDqg+2DzZduCLzrTia2cyvk0/ZM/iZx4mER
> dEr/VxqHD3VILs9RaRegAhJhldXRQLIQTO7ErBBDpqWeCtWVYpoNz4iCxTIM5Cuf
> ReYNnyicsbkqWletNw+vHX/bvZ8=
> -----END CERTIFICATE-----
>
> Configure SSLAuthorityChain in caldavd.plist
>
> This part is pretty easy. Just add the following stanza to the config file:
>
> <!-- SSL Authority Chain File -->
> <key>SSLAuthorityChain</key>
> <string>foo.com.chcrt</string>
> We use 'chcrt' to denote 'chain cert', which is the concatenated representation of the authority chain from server to root.
>
>
>
> Errata
>
> Odds and ends that may be useful in configuring or troubleshooting this stuff
>
> Show cert details
>
> In particular, two important attributes you'll see here are Issuer and Subject. Issuer identifies the CA that signed this cert, and subject identifies the owner of this cert. This is useful to verify the order of the certs in the chain file.
> openssl x509 -text -in foo.crt
> Examine a keychain's contents
>
> sudo security dump-keychain /System/Library/Keychains SystemRootCertificates.keychain | grep alis
> Remove a trusted cert from Keychain
>
> Sadly, this works on 10.5.8 and later, but not 10.5.7. The argument after -c is the name of the cert, which is shown on the 'alis' line of the dump-keychain output.
> sudo security delete-certificate -c "Entrust Certification Authority - L1B" /Library/Keychains/System.keychain
> Validate the SSL cert chain of a running service
>
> Remember that each cert can be decoded if necessary; see above.
> openssl s_client -showcerts -connect foo.apple.com:8443
>
> On Feb 9, 2014, at 6:41 AM, Pascal Dallaire <pascaldallaire at cre-gim.net> wrote:
>
>> Hello to the list,
>>
>> Running CalendarServer 4.2 on Snow Leopard, using the supplied SSL certificates that’s self-signed and expired. I tried to change to a CA certificate with information in plist about SSLCertificate, SSLAuthorityChain and SSLPrivateKey. The exact same files work a charm in Apache, but when trying in CalendarServer, I get an SSL handshake error :
>> -----
>> openssl s_client -connect mycalserver:8443
>> CONNECTED(00000003)
>> 45947:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-50/src/ssl/s23_lib.c:182:
>> -----
>> openssl s_client -connect mycalserver:8443 -servername realnameofcalserver
>> CONNECTED(00000003)
>> 45960:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-50/src/ssl/s23_clnt.c:602:
>> -----
>> I don’t know the problem here… This certificate was issued with a CSR made from the default OpenSSL on Snow Leopard (0.98r)
>>
>> Thanks whoever who could help
>> Pascal
>> _______________________________________________
>> calendarserver-users mailing list
>> calendarserver-users at lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/calendarserver-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/calendarserver-users/attachments/20140214/eed43551/attachment.html>
More information about the calendarserver-users
mailing list