I understand the differences are subtle because a lot of the terminology overlaps, but these are two very different activities. In the article you linked to, the steps described are intended to strengthen the service NiFi is providing and the ability of users to connect. As an analogy, let's describe building a bank.
By default, the bank is built of wood, has large clear windows with no blinds, and no official sign out front. You've taped a piece of paper saying "GeoffreyBank" to the door (this is plaintext, default, unencrypted HTTP communication from your browser to http://localhost:8080/nifi).
Now, of course, you want to secure your bank. It is going to store valuable items, and people will not use it if they do not trust that you are protecting their property. So, you build stronger walls and put an inner office so that their transactions cannot simply be observed by anyone on the street and you have professional signage so they can recognize that it is the correct bank.
This is analogous to protecting your NiFi installation with HTTPS. The server identity can be verified by clients checking the provided server certificate signature against their browser-default truststore, which prevents imposter sites from claiming to be your NiFi instance. Similarly, providing a private key to the server allows the client and server to encrypt all communications between them, so even though they are riding over unprotected public internet (coffee shop WiFi, carrier networks, etc.), an attacker cannot intercept and read your banking activities. Your NiFi installation is now available at https://localhost:8443/nifi. Note the changed protocol and port.
That is what part 1 of the article you linked to describes.
You also must ensure that your customers are accessing the correct accounts, which means ensuring they are who they say they are. This is the problem of client authentication. In a physical bank, you might require a driver's license or their issued ATM card in order to complete a transaction (something only the correct individual would have). You might also require a PIN (something they know). By the way, this is referred to as "multi-factor authentication" or "2FA". NiFi allows for "something you know" authentication by integrating with services like LDAP and Active Directory (Kerberos* coming soon), which permits a user to enter a username and password and be authenticated against the credential store. It also allows for "something you have" authentication by accepting client certificates. In this case, instead of identifying the server, this is a certificate which lives on the user's machine (laptop, smartphone, etc.) and uniquely identifies that person as an entity. It can also be used to mutually authenticate server-to-server communications. Because this requires some significant infrastructure investments, it is not common in small-to-medium organizations, but is more prevalent in large-scale organizations and government.
- Kerberos is technically "something you have" when providing the keytab file and TGT, but "something you know" when using a password to derive a symmetric key for the TGS.
That is what part 2 of the article you linked to describes.
Now we get to what Nejm is asking for. I, as a customer, ask you, GeoffreyBank, to transfer some of my money to OtherBank. If you just grabbed some of my cash, walked out the door, and came back and said, "Yeah, I did it," how much trust should I bestow on you? Even if I trust that you executed my request with good intentions, how do I know that the "OtherBank" you gave the money to is not an imposter? Rather, I might prefer that you use an armored truck, generated some physical receipt that is signed off by OtherBank, etc. Here we are describing the security of NiFi interacting with some other server, not a user. In this case, Facebook's Graph API is "OtherBank". NiFi is requesting data from Facebook to ingest, and Nejm wants to ensure that the connection between NiFi and Facebook is as secure as possible. To do that, NiFi must first verify that the endpoint it is connecting to is, in fact, Facebook. It requests and verifies Facebook's server certificate, then the signing certificate (DigiCert's intermediate CA), then the signing certificate of the intermediate (DigiCert's Root CA), and as it has that certificate pre-loaded into the JRE/JDK cacerts, it trusts that chain. It then uses the Facebook certificate's public key to generate a premaster secret (PMS) and eventually a master secret (MS) to derive multiple symmetric keys for encryption to/from Facebook's server. This is important because Nejm is likely requesting personally identifiable information (PII) about users from Facebook, and this content should be protected (confidentiality) and verified (integrity). By intercepting and modifying this data, an attacker could both gain access to data they should not be able to view, and manipulate or provide false data to NiFi that could generate incorrect results in whatever downstream processing occurs.
I hope this clarifies the differences above. I know this is a very complicated topic and the subtle intricacies are often difficult to communicate.