1. Cert issuance and approval from UI (manual, maul dual cert, agent
authenticated server cert)
2. Cert issuance in installation of other subsystems
3. Cert issuance (user and server) from RA.
4. Cert issuance and approval from restful interface using CATest
-- two step (create cert request/ agent approval) user and server certs
-- single step (agent approved user and server certs)
If a REST method returns a Response object it has to be handled
manually. A new getEntity() method has been added to obtain the
entity from the Response object and also map HTTP errors into
Endi S. Dewata
Generally the user LDAP entry does not contain a seeAlso attribute
unless it's a special database user. The UGSubsystem.removeUserCert()
would fail because it tried to remove the seeAlso attribute. Now the
code has been fixed to remove the seeAlso using a separate modify
operation and ignore the error if it fails due to missing attribute.
Endi S. Dewata
On 06/26/2012 07:06 AM, Fabian Bertholm wrote:
> I am not sure what the implications will be but I think the redhat PKI
> system is at least using the same hardware.
> You should read this paper.
> What does this mean for us as users?
The following response was provided by Robert Relyea:
For most token users, nothing. The researchers have not extracted
the RSA private key, they extracted a symmetric key that is
encrypted to the private key on the token. In environments where the
token does not support decrypt, and operate on FIPS level-3 or
above, this is big news, but for deployments which use a basic
"RSA-op" function, not even separate Sign/Decrypt functions, you can
simply decrypt the blob and get the symmetric key.
The paper is definitely worthy of attention, but for most
deployments it will have little or now impact.
> Best regard,
> Fabian Bertholm
> Pki-users mailing list
Attached is a patch that I've just tested locally to publish certs to a
LDAP directory easily if you have also setup authentication for user
certs using LDAP. I noticed an attribute stored in the internal db
which was the full DN of the authenticated user and that's what this
uses. (I also specify a predicate on the publish rule of
profileId==caDirUserDualCert to restrict the candidate certs to the