Network Ports and Protocols

Your workstations, servers, network domain controllers and applications need to validate the revocation status of the PIV certificates and all intermediate certificate authority certificates. In addition, the certificate chain path building may retrieve and download the intermediate certificate authority certificates.

The validation occurs in real-time (with some caching) and requires ensuring network traffic is open and available to the destination web services, ports, and protocols. Many US Federal agencies implement a layered network security model with demilitarized zones (DMZs), proxies and Trusted Internet Connections (TICs) to monitor, defend and protect the networks, applications and users.

This page includes information to help you verify your network configurations:

• Verifying and Troubleshooting
• Web services for validating PIV certificates
• Web services for the Federal Public Key Infrastructure

Verifying and Troubleshooting

Non-accessible endpoints for the web services due to firewalls blocking access is a very common root cause for errors. If you encounter user errors including “Cannot validate” and similar domain controller errors, your first troubleshooting step should be to verify your network and access.

Troubleshooting if the web services endpoints are accessible or blocked by firewall rules is simple to begin. You have the basic four utility tools for troubleshooting:

• certutil (Microsoft)
• openssl
• nslookup
• tracert

For the typical network domain, certutil will be your best option to identify a number of possible root causes. There are many options available in the certutil utility tool, and two are covered here.

Export your public key and certificate for PIV Authentication to a .cer file (mypiv_auth.cer), and run the following command in a command line from workstation(s) and domain controller(s):

  certutil -verify -urlfetch mypiv_auth.cer >>verify_piv.txt

The text file output will include a full check against all options for CRLs, OCSP, intermediate certificates to verify a trust chain, and the root (COMMON). Review all items and ensure at least one successful verification message is included for each check. You may see errors for the LDAP verifications and these can be ignored if a CRL or OCSP check is successful.

There is also a graphical user interface to help perform these verification checks.

  certutil -v -url mypiv_auth.cer

The graphical user interface allows you to check OCSP, CRL, and AIA (intermediate certificate retrievals).

Web services for validating PIV certificates

Revocation status is validated using using either Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs). To meet your initial network requirements, you should ensure the OCSP and CRL URLs included in your agency users’ PIV Authentication certificates are accessible from all workstations and domain controllers.

Lightweight Directory Application Protocol (LDAP) for retrieving information is not preferred and has been increasingly deprecated therefore LDAP is not included.

There are dozens of OCSP and CRL URLs for all issued PIV credentials. If you have users with PIV credentials from other agencies or partners, identifying all the URLs to verify against your network configurations will be more complex.

Web services for the Federal Public Key Infrastructure

The Federal Common Policy Certificate Authority (COMMON) is the root certificate authority and has web services to publish both certificate chains (p7b files) and CRLs for all intermediate certificate authorities which the root signs.

To enable communications with these Federal Common Policy Certificate Authority services, including those currently operational and any expansion, you should verify outbound communications to the Federal Public Key Infrastructure Management Authority address space as registered with the American Registry for Internet Numbers (ARIN) under FPKI-NET:

You should consider allowing two protocols (port): HTTP (80) and DNS (53). Although the web services for publishing CRLs is not currently served over HTTPS (443), you may want to allow HTTPS (443) to future proof for any expansion.