The diagram you present describes the situation wherein only one side identifies itself to the other via an SSL certificate. This is very common on the web, but it is insufficient for Puppet.
With a Puppet agent / master setup, not only must the master prove its identity to agents, but the agents must also prove their identities to the master. This is an example of an arrangement sometimes called "mutual authentication". Each side does this by presenting an SSL certificate to the other that the other is prepared to trust, on account of that certificate being signed by a trusted authority. This additional exchange looks like your diagram's steps 2 and 3, but running in the opposite direction.
Most commonly in Puppet, the master and agents all rely on and trust a private CA run by the master, but they may instead rely on an external CA. Wherever they reside and whoever operates them, CAs are identified by their own certificates. These are involved in determining whether other certificates are trusted, but not in encrypting the data exchanged by communicating parties. Your diagram does not cover obtaining a certificate, and it summarizes all aspects of whether a given certificate is trusted as "3. Browser validates".
Having established that agent and master each know and trust the other, securing data transmission over the connection proceeds just the same way in a mutual authentication system that it does in a server-authentication system. Data passing in both directions (not shown in your diagram) is encrypted with the negotiated symmetric cipher and key.
