1

Every 15 minutes or so I get this message in my system.log

Apr 25 22:05:36 Ivans-MacBook-Pro.local apsd[194]: Unrecognized leaf certificate
Apr 25 22:20:57 Ivans-MacBook-Pro.local apsd[194]: Unrecognized leaf certificate

Now I have figured out approximately what is what:

apsd - Apple Push notification Service Daemon
Leaf certificate - The first certificate in the certificate chain(Not sure, mentioned on some Microsoft site)

But what does it mean? How serious is it? What exactly is the leaf certificate? Do I have a false/bogus certificate on my system?

It's a pretty clean Mac OS X Mavericks 10.9.2 install, only few apps from the official Mac App Store installed(Xcode and few other coding editors)

Improve this question

3 Answers 3

Reset to default
7

A "leaf certificate" is what is more commonly known as end-entity certificate. Certificates come in chains, starting with the root CA, each certificate being the CA which issued (signed) the next one. The last certificate is the non-CA certificate which contains the public key you actually want to use.

If the PKI is represented as a tree, with the root CA as, yeah, the root, then end-entity certificates are the leaves.

The Apple Push Notification Service is a system in which a component of your system connects back to Apple to get "notifications" (small messages related to your installed applications). From the messages you observe, it is plausible that the connection uses SSL, and the server certificate (on the Apple side of things) was recently changed, and (for some reason) does not make apsd happy.

Some Google searches show that other people get these messages, and don't seem to notice any bad consequence. This might be a consequence of some dysfunction at Apple's, and could possibly fix itself in a few hours. To be sure, try to run Wireshark to see if you could get a copy of the network traffic: if there indeed is some SSL, then Wireshark will show it, and you will get a copy of the offending certificate.

Improve this answer
2
  • Looking at the log archive, I see this message appearing every 15 minutes for the last 7 days. And the logs are kept for 7 days, so it is probably even more... Can I do something else beside Wireshark? Was there a system built-in tcpdump? I'm obliged(policy) not to install anything on this machine not originating from official App Store...
    – Ivan Kovacevic
    Apr 25, 2014 at 21:13
  • Yup there is a tcpdump utility that can be called from the console. I've used it, and I have analysed the traffic on another machine in Wireshark. I'll post the results as an answer.
    – Ivan Kovacevic
    Apr 26, 2014 at 18:17
2

apsd -- Apple Push Notification service daemon

By sampling the running process in the Activity Monitor I get this:

Path: /System/Library/PrivateFrameworks/ApplePushService.framework/apsd
Version: 206.2
Code Type: X86-64
Parent Process: launchd [1]

The process is launched at system boot and remains constantly active. Every 15 minutes a log message is generated in system.log file(Viewable by the Console app), containing a warning that there is a Unrecognized leaf certificate. I've used tcpdump/Wireshark to sample the network traffic four individual times(just to be sure).

First time:
Destination: 4-courier.push.apple.com (17.172.232.62)
Port: 5223

Second time:
Destination: 14-courier.push.apple.com (17.149.32.65)
Port: 5223

Third time:
Destination: 44-courier.push.apple.com (17.172.233.136)
Port: 5223

Fourth time:
Destination: 23-courier.push.apple.com (17.149.36.193)
Port: 5223

The IP addresses really do belong to Apple, 

NetRange: 17.0.0.0 - 17.255.255.255
CIDR: 17.0.0.0/8
OriginAS: 
NetName: APPLE-WWNET
NetHandle: NET-17-0-0-0-1

OrgName: Apple Inc.
OrgId: APPLEC-1-Z
Address: 20400 Stevens Creek Blvd., City Center Bldg 3
City: Cupertino
StateProv: CA
PostalCode: 95014
Country: US
RegDate: 2009-12-14
Updated: 2011-03-08
Ref: http://whois.arin.net/rest/org/APPLEC-1-Z

The traffic was(as expected) SSL on custom port 5223 as described here: http://support.apple.com/kb/HT6175

Port: 5223
TCP or UDP: TCP
Service or Protocol Name: Apple Push Notification Service
RFC: -
Service Name: -
Used by / Additional information: iCloud DAV Services (Contacts, Calendars, and Bookmarks), APNS, FaceTime, Game Center, Photo Stream, Back to My Mac

The certificate that the server is sending however looks like this:

Identity: courier.push.apple.com
Verified by: Entrust Certification Authority - L1C
Expires: 11/21/2015

Subject Name
C (Country):    US
ST (State): California
L (Locality):   Cupertino
O (Organization):   Apple Inc.
CN (Common Name):   courier.push.apple.com

Apple obviously changed something in the load balancing scheme because apsd is never connecting directly to the domain courier.push.apple.com. And the service is not reachable through that domain if one attempts to connect manually from the browser (as https://courier.push.apple.com:5223) either.

However on mentioned subdomains:
https://4-courier.push.apple.com:5223
https://14-courier.push.apple.com:5223
https://44-courier.push.apple.com:5223
https://23-courier.push.apple.com:5223

It is possible and the error appears: "This certificate is not valid(host name mismatch)". What I believe is happening is that apsd is reporting the same thing, but the developers decided to write that in the logs as "Unrecognized leaf certificate".

Apple should create a new certificate that includes a wildcard (CN (Common Name): *courier.push.apple.com) to correct this issue. I've submitted a Feedback/Bug Report on http://www.apple.com/feedback/macosx.html

But this could be more serious then just an annoying log message, if apsd is actually ignoring the wrong certificate and just continuing to work!

Continued here: Is Apple's push notification service implementation vulnerable to a MitM attack

Improve this answer
0

As mentioned in the answers above a leaf certificate is another name for an individual server certificate. Looking at Ivan's Answer above, it's pretty much spot on except most SSL/TTLS implications don't rely on the CN (Common Name) any more. Instead they rely on the SAN field in modern Certificates.

The SAN field was originally intended to be used when an individual certificate was to be used on a single host with multiple hostnames going back to the same IP address.

Looking at the certificate for 4-courier.push.apple.com and viewing it's SAN field:

Subject Alternative Name
    DNS Name=courier.push.apple.com
    DNS Name=courier2.push.apple.com
    DNS Name=windows.courier.push.apple.com

Repeating for the certificate for 44-courier.push.apple.com

Subject Alternative Name
    DNS Name=courier.push.apple.com
    DNS Name=courier2.push.apple.com
    DNS Name=windows.courier.push.apple.com

It looks as if Apple have failed to list all the possible servers using the certificate. Thus when the daemon connects to either of the above URL's the connection SHOULD fail because of invalid SNI (Server Name Identification) checks.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .