← Todos os guias de estudo
PFAA-001
Certified Expert - PingFederate
Parte de Certified Expert - PingFederate
Each voucher code is valid for a single exam attempt only; once redeemed it cannot be reused. Exam covers PingFederate version 11 or later.
Material de estudo independente, construído a partir do blueprint público da prova. Sem afiliação, autorização ou endosso da ping. Os objetivos são transcritos e mapeados à mão, então esta página pode conter erros ou estar defasada em relação ao material atual do fabricante: objetivos, versões, numeração e disponibilidade mudam sem aviso. Trate o portal de certificação da própria ping como a fonte da verdade e confira nele antes de agendar qualquer coisa.
Objective 1: Advanced Configuration
PFAA-001.1.01 Configure attribute mappings from an external data store with failover.
O que saber:- Failover on a data store means a second source is queried when the first is unreachable.
- Configure multiple LDAP hostnames on the data store so the connection itself fails over.
- Failover addresses availability of the source, not missing data within a reachable source.
- Test by taking the primary offline, not by reasoning about the configuration.
- Connection timeouts must be short enough that failover happens faster than the user gives up.
PFAA-001.1.02 Configure attribute mappings from an external data store with failsafe mappings.
O que saber:- Failsafe mapping supplies a default value when the lookup succeeds but returns nothing.
- This is the distinction the exam draws: failover is about the source being down, failsafe is about the attribute being absent.
- Without a failsafe, a missing attribute can fail the whole SSO transaction.
- Choose defaults that are safe if they reach the service provider, since they will.
- Log when the failsafe fires, or silent defaults hide a data-quality problem.
PFAA-001.1.03 Configure attribute mappings from an external data store using OGNL.
O que saber:- OGNL expressions compute attribute values from data-store results and other context.
- Expressions can concatenate, conditionally select, and transform values during mapping.
- Enable expressions explicitly; they are disabled by default because they are powerful.
- Keep expressions short and testable; complex logic belongs in the data source or an adapter.
- An expression that throws will fail the transaction, so handle null cases deliberately.
PFAA-001.1.04 Create custom attributes using OGNL.
O que saber:- Custom attributes are contract entries populated by expression rather than by direct lookup.
- Extend the attribute contract first, then fulfil the new attribute with an OGNL expression.
- Typical uses: deriving a role string, normalizing case, or combining given and family names.
- The service provider only receives what the contract carries, so contract and expression must agree.
- Test with representative data including the awkward cases, not just a clean sample user.
PFAA-001.1.05 Customize the HTML Form Adapter.
O que saber:- The HTML Form Adapter renders the username and password login page.
- Customization uses the template files in the server's template directory, with localization files for text.
- Branding changes belong in templates and CSS; behavior changes belong in adapter configuration.
- Template changes must be replicated to every node in a cluster.
- Keep customizations minimal and documented, because they must be reapplied at upgrade.
PFAA-001.1.06 Self-service password reset.
O que saber:- Self-service password reset lets users set a new password without an administrator.
- Configuration is on the HTML Form Adapter and requires a password credential validator that supports writes.
- Verification method matters: email one-time link, one-time password, or challenge questions each have different security properties.
- Rate limiting and account-enumeration protection belong in the design; a reset flow that reveals whether an account exists is a finding.
- The directory account used by PingFederate needs the rights to change passwords.
PFAA-001.1.07 Self-service account recovery.
O que saber:- Account recovery unlocks or restores access after lockout, distinct from resetting a known-bad password.
- It uses the same verification mechanisms as password reset and the same enumeration concerns.
- Coordinate with the directory's lockout policy so recovery actually clears the lock.
- Audit recovery events specifically; they are a common target for social engineering.
- Decide whether recovery requires stronger verification than reset, and justify the choice.
PFAA-001.1.08 Self-service username recovery.
O que saber:- Username recovery tells a user which username is associated with a verified identifier such as an email address.
- This is the highest enumeration risk of the three self-service flows, so responses should be uniform regardless of whether the account exists.
- Delivery should go to the registered channel, never displayed on screen.
- Some organizations disable this entirely; that is a legitimate design decision.
- Rate limit aggressively and log every attempt.
PFAA-001.1.09 Advanced use of authentication policies.
O que saber:- Authentication policies are a decision tree over adapters and selectors, evaluated per request.
- Selectors branch on context: network range, requested authentication context, client, or attribute values.
- Policy contracts carry attributes out of the tree to the connection, decoupling the tree from the target.
- Advanced use includes step-up authentication, where a branch requires a second factor before reaching success.
- Draw the tree before building it; policies are hard to read in the console once they grow.
PFAA-001.1.10 Local identity profiles.
O que saber:- Local identity profiles support registration and profile management for users PingFederate itself manages.
- They define the fields collected, the data store where they are written, and the associated templates.
- Registration, profile update, and email verification are the common flows.
- This is for use cases without an existing enterprise directory of these users, typically customer identity.
- Field validation and required-attribute handling belong in the profile definition.
PFAA-001.1.11 SP Target URL Mapping.
O que saber:- SP target URL mapping decides where the user lands at the service provider after SSO.
- It maps a requested target to an allowed destination, rather than trusting an arbitrary supplied URL.
- This is an open-redirect control as much as a usability feature.
- Wildcards must be scoped carefully so they cannot match an attacker-controlled host.
- Coordinate with the service provider on the exact URLs their application uses.
PFAA-001.1.12 Configure Redirect Validation.
O que saber:- Redirect validation restricts the URLs PingFederate will redirect a browser to after authentication or logout.
- Configure allowed target resources for SSO and for SLO separately.
- Without it, a crafted target parameter turns the identity provider into an open redirector, which is a phishing amplifier.
- Validation should match on scheme and host, not merely on a substring.
- Test with a deliberately hostile value to confirm the rejection path works.
PFAA-001.1.13 Using RelayState to request a specific resource.
O que saber:- RelayState carries application state through the SAML exchange so the user returns to the resource they requested.
- The identity provider echoes it back; it is opaque to the protocol.
- Because it is attacker-influenceable, it must be validated against redirect-validation rules before use.
- Size limits apply; large state should be stored server-side with a reference in RelayState.
- Understand the difference between RelayState and the target parameter of an IdP-initiated URL.
PFAA-001.1.14 Configure certificate revocation checking.
O que saber:- Revocation checking confirms a presented certificate has not been revoked, via CRL or OCSP.
- OCSP gives fresher answers; CRLs are simpler but can be large and stale.
- Decide the failure behavior when the revocation source is unreachable: fail open or fail closed, each with consequences.
- Network access to the CRL distribution point or OCSP responder must exist from the PingFederate host.
- Cache settings trade freshness against latency and load on the responder.
PFAA-001.1.15 Configure certificate rotation for self-signed certificates.
O que saber:- Self-signed certificates in PingFederate can be rotated so a new certificate is published before the old one stops being used.
- The rotation creates a successor certificate that appears in metadata, letting partners pick it up in advance.
- Partners consuming metadata automatically will follow; partners with pinned certificates need manual coordination.
- Plan rotation before expiry, not at it; a signing certificate that expires breaks every federation at once.
- Verify each partner has accepted the new key before activating it.
Objective 2: SSO IdP/SP Configuration
PFAA-001.2.01 Create custom URLs using single sign-on (SSO) endpoint variables
O que saber:- SSO endpoint variables let a single startSSO URL serve multiple targets by parameter.
- Common parameters: PartnerSpId, TargetResource, and IdP adapter selection.
- Custom URLs simplify bookmarking and application integration without a connection per target.
- Every parameter that influences redirection must be covered by redirect validation.
- Document the URL format for application teams, since malformed URLs are a frequent support issue.
PFAA-001.2.02 Configure identity provider to service provider (IdP-to-SP) bridging
O que saber:- IdP-to-SP bridging makes PingFederate act as a service provider to an upstream identity provider and as an identity provider to a downstream service provider.
- This is the federation hub pattern: many upstream identity sources, many downstream applications, one translation point.
- Attribute mapping happens twice, and the contract must carry attributes through both hops.
- Authentication policies decide which upstream identity provider handles a given request.
- Bridging concentrates trust, so the hub's own security and availability become critical.
PFAA-001.2.03 Configure session cookies
O que saber:- Session cookies represent the authenticated session at PingFederate itself.
- Configure timeouts, whether the session is tracked, and the scope of the cookie.
- Authentication sessions can be stored so re-authentication is not required across applications.
- Cookie attributes (Secure, HttpOnly, SameSite) must be set appropriately for the deployment.
- Session behavior interacts with single logout; understand what a logout actually terminates.
Objective 3: OAuth/OIDC Configuration
PFAA-001.3.01 Configure dynamic client registration
O que saber:- Dynamic client registration lets OAuth clients register themselves at runtime rather than being created by an administrator.
- Access to the registration endpoint must be controlled, typically by an initial access token, or anyone can create clients.
- Client registration policies constrain what a self-registering client may request.
- Registered clients receive credentials and a registration access token for later management.
- This is essential at scale and dangerous when unrestricted; the policy configuration is the control.
PFAA-001.3.02 Configure an external DB for persistent grants
O que saber:- Persistent grants record a user's consent and refresh-token state, and must survive restarts.
- An external database gives durability and shared visibility across a cluster.
- Schema is supplied by PingFederate; the database account needs the documented rights.
- Grant lifetime and cleanup of expired grants are operational settings with storage consequences.
- Without external storage, grants are limited in ways that break refresh-token behavior at scale.
Objective 4: Clustering
PFAA-001.4.01 Configure an adaptive cluster
O que saber:- An adaptive cluster distributes runtime state dynamically among engine nodes without dedicated state servers.
- Nodes discover each other and share state, which simplifies deployment.
- It suits deployments where all engines are equivalent and network conditions between them are good.
- Understand the rebalancing behavior when a node joins or leaves.
- Compare against the directed model before choosing; the trade is simplicity versus explicit control.
PFAA-001.4.02 Configure dedicated state servers in a directed cluster
O que saber:- In a directed cluster, specific nodes are designated as state servers holding runtime state for the others.
- Engines are configured with the state servers they use, making the topology explicit.
- This gives predictable placement, which matters across latency boundaries.
- State server failure has a defined impact that must be understood and tested.
- Sizing the state servers is a separate capacity exercise from sizing the engines.
PFAA-001.4.03 Configure sub-clusters in a directed cluster
O que saber:- Sub-clusters group nodes, typically by data centre or region, so state is shared within a group rather than globally.
- This limits cross-site chatter and keeps latency-sensitive state local.
- Requests must be steered so a user's session stays within the sub-cluster that holds its state.
- Cross-sub-cluster failover behavior is a design decision with a user-visible consequence: re-authentication.
- Configuration must be consistent across every node or the grouping silently misbehaves.
PFAA-001.4.04 Configure cluster runtime state-management services
O que saber:- Runtime state management covers sessions, grants, and other data that must be consistent across nodes.
- Services are configured per state type, so different data can use different strategies.
- Some state can be regenerated (re-authenticate) and some cannot (consent); treat them differently.
- Monitor replication of state, not just node liveness.
- Test node loss deliberately and observe what users experience.
Objective 5: Troubleshooting
PFAA-001.5.01 Interpret the contents of individual log files
O que saber:- Key logs: server.log for runtime and errors, transaction and audit logs for per-request detail, admin logs for configuration changes.
- The audit log records the SSO transaction with identity, connection, and result, which is the first place to look for a failed login.
- Correlate across logs using the tracking or transaction identifier.
- Timestamps must be synchronized across cluster nodes or correlation is impossible.
- Know which log answers which question before an incident, not during one.
PFAA-001.5.02 Change logging levels
O que saber:- Logging levels are set in log4j2.xml, per logger, and can be changed for a specific component rather than globally.
- DEBUG on the right package is far more useful than DEBUG everywhere, which buries the signal and hurts performance.
- Some changes require a restart while others are picked up on the configured monitor interval.
- Raise the level, reproduce, capture, and lower it again as a disciplined loop.
- Never leave verbose logging on in production; it can log sensitive data.
PFAA-001.5.03 Configure log file rotation using log4j2.xml
O que saber:- Rotation is configured with log4j2 appenders using time-based or size-based triggering policies.
- A rollover strategy sets how many archived files are kept.
- Rotation prevents a single unbounded file and makes archival practical.
- Align rotation with your log-shipping cadence so files are complete when collected.
- Confirm disk capacity accounts for the retained set, not just the active file.
PFAA-001.5.04 Configure custom log listeners using log4j2.xml
O que saber:- Custom appenders in log4j2.xml can direct specific loggers to their own files or to remote destinations.
- Syslog and socket appenders push logs to central collection without a separate agent.
- Filters let one appender receive only the events that matter, keeping targeted logs small.
- Pattern layouts control the format, which downstream parsers depend on; changing it breaks them.
- Validate the configuration on one node before rolling it across the cluster.
PFAA-001.5.05 Configure database logging
O que saber:- Database logging writes audit records to a relational database instead of, or alongside, files.
- It requires a JDBC data store and the schema PingFederate supplies.
- Querying audit data becomes practical, which is why compliance teams ask for it.
- Database availability now affects logging; understand the behavior when the database is unreachable.
- Retention and archival of the audit table is an operational responsibility that files handled implicitly.
Objective 6: Basic Configuration
PFAA-001.6.01 Configure an HTML Form Adapter
O que saber:- The HTML Form Adapter authenticates users with a username and password against a password credential validator.
- Configuration covers the validator, session behavior, and which self-service features are exposed.
- The adapter contract defines which attributes it makes available to policies and connections.
- Challenge and lockout behavior come from the validator and the underlying directory, not the adapter alone.
- This is the default interactive adapter and the base for most authentication policies.
PFAA-001.6.02 Customize the HTML Form Adapter
O que saber:- Customization means editing the velocity templates and the localization property files.
- Files live in the server template directory and must be identical on every cluster node.
- Separate branding (CSS, images) from logic; logic in templates is hard to maintain across upgrades.
- Keep a record of every customized file, because upgrades ship new defaults that must be merged.
- Test the customized page for accessibility and for correct behavior on error, not just the happy path.
PFAA-001.6.03 Configure an HTTP Basic Adapter
O que saber:- The HTTP Basic Adapter authenticates using the browser's basic authentication prompt.
- It is simple and unbranded, which makes it suitable for service or test scenarios rather than user-facing login.
- Credentials are sent on every request, so TLS is mandatory.
- There is no logout mechanism for basic authentication, which is a real limitation.
- It still uses a password credential validator, so the backing directory configuration is the same.
PFAA-001.6.04 Configure a Kerberos Adapter
O que saber:- The Kerberos Adapter provides desktop single sign-on for domain-joined machines.
- It requires a service account and keytab in Active Directory, plus a correct service principal name.
- Browsers must be configured to trust the PingFederate hostname for integrated authentication.
- Clock skew between the domain controller and PingFederate breaks Kerberos; time synchronization is mandatory.
- Provide a fallback adapter for machines that cannot use Kerberos, or remote users are locked out.
PFAA-001.6.05 Configure an OpenToken Adapter
O que saber:- The OpenToken Adapter exchanges identity with an application using a shared-secret encrypted token.
- It is an agentless integration where the application uses an OpenToken agent library.
- Shared secret, transport (cookie or query parameter), and token lifetime are the key settings.
- Both sides must agree on the cipher suite and the attribute names carried in the token.
- It is a legacy integration pattern; prefer standards-based options where the application supports them.
PFAA-001.6.06 Configure a One-Time Passcode Adapter
O que saber:- The One-Time Passcode Adapter delivers a code out of band, typically by email or SMS.
- It is used as a second factor in an authentication policy, after a primary adapter.
- Configure the delivery channel, code length, expiry, and retry limits.
- The user's contact attribute must be retrievable, so the data store mapping is part of the setup.
- Delivery failures are the operational risk; monitor them and provide an alternative factor.
PFAA-001.6.07 Configure a RefID Adapter
O que saber:- The RefID Adapter passes a reference identifier rather than the identity itself, which the partner resolves separately.
- It suits integrations where attributes must not travel in the token.
- The reference must be resolvable by the receiving side within its validity window.
- Understand the lifetime and single-use characteristics of the reference.
- This is a privacy-preserving pattern: the token carries a pointer, not the data.
PFAA-001.6.08 Configure an X509 Adapter
O que saber:- The X509 Adapter authenticates using a client certificate presented during the TLS handshake.
- The connector must request or require client certificates, and the issuing CA must be trusted.
- Attributes are extracted from the certificate subject or SAN and mapped into the contract.
- Revocation checking should be enabled, or a revoked certificate still authenticates.
- This is strong authentication tied to a device or a smartcard rather than to knowledge.
PFAA-001.6.09 Configure a Composite Adapter
O que saber:- The Composite Adapter chains several adapters so multiple factors are collected in one adapter instance.
- Each chained adapter contributes attributes; the composite contract exposes the combination.
- Ordering matters, and the policy of which adapters are required versus optional is part of the configuration.
- Authentication policies can express similar logic; the composite is simpler for a fixed chain.
- Test the failure of each member adapter to confirm the overall behavior is what you intended.
PFAA-001.6.10 Configure attribute mappings from an external data store
O que saber:- Data store mapping enriches the identity with attributes fetched at authentication time.
- Configure the data store, the search filter or query, and the mapping into contract attributes.
- The search filter is the critical piece: it must uniquely identify the user, and it must be indexed at the directory.
- Failed lookups and empty results are different failure modes; handle both.
- Every mapped attribute costs a lookup, so retrieve what is needed and no more.
PFAA-001.6.11 Create custom attributes using OGNL
O que saber:- OGNL expressions in fulfilment produce values that are not directly present in the source.
- They must be explicitly enabled in configuration before they can be used.
- Common patterns: conditional defaults, string manipulation, and joining values from multiple sources.
- Expressions execute per transaction, so keep them cheap and null-safe.
- Validate against real data, because a null in production will throw where the test data did not.
PFAA-001.6.12 Configure an SP/IdP SAML connection using the POST binding
O que saber:- A SAML connection using POST binding sends the assertion in a form auto-submitted by the browser.
- Configuration requires the partner entity ID, ACS URL, signing certificate, and the attribute contract.
- POST binding suits large assertions; redirect binding is size-limited by URL length.
- Assertion signing and optional encryption are configured per connection and must match partner expectations.
- Metadata exchange is the reliable way to get these values right rather than transcribing them.
PFAA-001.6.13 Configure an SP/IdP connection using OpenID Connect (OIDC)
O que saber:- An OIDC connection uses OAuth flows with an ID token instead of a SAML assertion.
- The relying party is registered as an OAuth client with redirect URIs and allowed grant types.
- OIDC policies determine what claims land in the ID token.
- Scopes control which claims the client may request, and the policy fulfils them.
- Discovery metadata lets clients configure themselves from the well-known endpoint.
PFAA-001.6.14 Configure an SP/IdP connection utilizing multiple ACS endpoints
O que saber:- Multiple ACS endpoints let one connection serve several service-provider environments or indexes.
- The assertion consumer service index or explicit URL in the request selects the endpoint.
- A default endpoint applies when none is specified.
- Each endpoint must be validated to prevent assertions being posted to an unintended location.
- This is how a single connection supports development, test, and production URLs where the partner requires it.
PFAA-001.6.15 Create custom URLs using SSO endpoint variables
O que saber:- Endpoint variables in a startSSO URL select the partner, the target resource, and the adapter to use.
- This enables deep linking from a portal into a specific application through the identity provider.
- All target values must satisfy redirect validation.
- Encode parameter values correctly, since unencoded characters are a common cause of failures.
- Publish the canonical URL format to application owners rather than letting each team invent one.
PFAA-001.6.16 Create OAuth clients
O que saber:- An OAuth client is defined by client ID, authentication method, allowed grant types, redirect URIs, and scopes.
- Client authentication options include shared secret, mutual TLS, and private key JWT; prefer the stronger options for confidential clients.
- Public clients (SPAs, native apps) must use authorization code with PKCE and cannot hold a secret.
- Redirect URIs must be exact-matched; wildcards here are an open-redirect and token-theft risk.
- Scope restrictions on the client limit what it can ever request, independent of user consent.
PFAA-001.6.17 Configure persistent grant settings
O que saber:- Persistent grants store the user's authorization so it need not be re-consented on every request.
- Settings cover grant lifetime, idle timeout, and whether grants are reusable across clients.
- Persistent grants underpin refresh tokens; without them refresh cannot survive a restart.
- Grant storage may be local or in an external database for cluster durability.
- Provide a revocation path, because a persistent grant is standing authorization until removed.
PFAA-001.6.18 Configure common scopes
O que saber:- Common scopes are available to any client that requests them, subject to the client's own restrictions.
- They form the shared vocabulary of the authorization server.
- Each scope should map to a meaningful capability, not to an implementation detail.
- Descriptions matter because they appear on the consent screen the user reads.
- Keep the common set small; proliferation makes consent meaningless.
PFAA-001.6.19 Configure exclusive scopes
O que saber:- Exclusive scopes are restricted so only explicitly permitted clients may request them.
- Use them for privileged capabilities that must never be granted to a general client.
- The client configuration must list the exclusive scope for the request to succeed.
- This is the mechanism for separating administrative APIs from ordinary ones at the authorization server.
- Audit which clients hold exclusive scopes as a periodic review.
PFAA-001.6.20 Configure internally referenced access tokens
O que saber:- Internally referenced access tokens are opaque strings; the resource server calls introspection to learn their meaning.
- Revocation is immediate because every validation consults the authorization server.
- The cost is a network round trip per validation, mitigated by caching at the resource server.
- Token contents never leave the authorization server, which is a privacy advantage.
- Choose this when revocation immediacy outweighs latency.
PFAA-001.6.21 Configure JWT access tokens
O que saber:- JWT access tokens are self-contained and validated locally against the signing key.
- The resource server must verify signature, issuer, audience, and expiry, and reject anything failing.
- Revocation is the weakness: a valid JWT remains valid until it expires, so lifetimes should be short.
- Access token management instances define the claims, signing algorithm, and lifetime.
- Publish keys via JWKS so resource servers can rotate without manual coordination.
PFAA-001.6.22 Configure attribute mapping for ROPC grant type
O que saber:- The resource owner password credentials grant sends the user's password to the client, which is why it is deprecated.
- Attribute mapping for ROPC has no browser interaction, so attributes come from the validator and data stores directly.
- Where legacy systems still require it, restrict it to specific trusted clients.
- The RFC 9700 security best practice is explicit that ROPC should not be used; document the migration plan.
- Treat any ROPC client as a high-value credential-handling component.
PFAA-001.6.23 Configure attribute mapping for all other grant types
O que saber:- Other grant types (authorization code, client credentials, device, token exchange) each have their own attribute-mapping configuration.
- Client credentials has no user, so the mapping draws from the client rather than an authenticated person.
- Authorization code maps from the authentication session and any data stores.
- The mapping determines what the access token carries, which is what the resource server will authorize on.
- Map only what the resource server needs; extra claims are unnecessary exposure and token bloat.
PFAA-001.6.24 Configure refresh tokens
O que saber:- Refresh tokens let a client obtain a new access token without user interaction.
- Configuration covers whether refresh tokens are issued, their lifetime, and whether they rotate on use.
- Rotation with reuse detection is the recommended posture for public clients: a replayed token invalidates the chain.
- Refresh tokens depend on persistent grants, so grant storage and lifetime govern them.
- A long-lived refresh token is a long-lived credential and should be protected accordingly.
PFAA-001.6.25 Configure OIDC policies
O que saber:- OIDC policies define which attributes become claims in the ID token and at the userinfo endpoint.
- A policy is bound to clients and can differ per client, so different applications receive different claims.
- Attribute sources and OGNL fulfilment work the same way as in SAML connections.
- Include only necessary claims; the ID token is visible to the client and often logged by it.
- The policy is where the identity contract with the application is actually defined.
PFAA-001.6.26 Configure OIDC attribute scopes
O que saber:- Attribute scopes bind claims to requested scopes, so a client receives extra claims only when it asks and is permitted.
- This implements data minimization: the profile scope yields profile claims, and nothing more by default.
- The mapping between scope and claim set is configured in the OIDC policy.
- Consent screens should reflect what each scope actually reveals.
- Review the scope-to-claim mapping when adding claims, or data leaks through an existing scope.
PFAA-001.6.27 Configure an external LDAP database
O que saber:- An external LDAP data store is configured with connection URLs, bind credentials, and connection pooling settings.
- Use LDAPS or StartTLS; the bind credential travels on every connection.
- The service account should have only the read rights it needs, plus write rights only if self-service requires them.
- Connection pool sizing and timeouts materially affect authentication latency under load.
- Multiple hostnames give failover; test it rather than assuming.
PFAA-001.6.28 Manage certificates
O que saber:- Certificate management covers signing certificates, SSL server certificates, and trusted partner certificates.
- Signing certificates appear in metadata and must be rotated with partner coordination.
- SSL server certificates protect the runtime and admin ports and are separate from signing keys.
- Import partner certificates into the correct trust context; a certificate in the wrong store does nothing.
- Track expiry for every certificate in the deployment; expiry is the most common federation outage.
PFAA-001.6.29 Manage certificate authorities (CAs)
O que saber:- Certificate authorities in the trust store determine which partner and backend certificates are accepted.
- Importing a CA trusts everything it issues, so the trust store should be curated rather than filled with defaults.
- Separate trust anchors for different purposes where the product allows it.
- Intermediate certificates must be present for chain validation to succeed.
- Review the trust store periodically; an unnecessary CA is unnecessary risk.
Fontes públicas, usadas de boa-fé
Estes guias são materiais de estudo independentes, montados a partir de conteúdo publicamente disponível: blueprints de exame publicados, documentação oficial de produto e catálogos de treinamento dos fabricantes. Nomes de produtos, códigos de exame e marcas pertencem a seus titulares e são usados apenas para identificar o assunto ensinado. Este site não é afiliado a nenhum fabricante aqui citado nem endossado por ele. Se você detém direitos sobre material publicado nesta página e entende que ele deve ser removido ou corrigido, envie a URL exata e uma breve nota sobre o problema pela página de contato; os pedidos são analisados com rapidez e boa-fé. Ler o aviso legal completo →