Let the user, upon installation, set the certificate subject base
for the dogtag CA. Certificate requests will automatically be given
this subject base, regardless of what is in the CSR.
The selfsign plugin does not currently support this dynamic name
re-assignment and will reject any incoming requests that don't
conform to the subject base.
The certificate subject base is stored in cn=ipaconfig but it does
NOT dynamically update the configuration, for dogtag at least. The
file /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg would need to
be updated and pki-cad restarted.
Add a new get_subject() helper and return the subject when retrieving
certificates.
Add a normalizer so that everything before and after the BEGIN/END
block is removed.
Need to add a few more places where the DN will not be automatically
normalized. The krb5 server expects a very specific format and normalizing
causes it to not work.
This profile enables subject validation and ensures that the subject
that the CA issues is uniform. The client can only request a specific
CN, the rest of the subject is fixed.
This is the first step of allowing the subject to be set at
installation time.
Also fix 2 more issues related to the return results migration.
The idnsUpdatePolicy takes a list of BIND dynamic update policies, each
of which must be terminated by ";". Also fix a minor error in the
documentation string.
Ignore NotImplementedError when revoking a certificate as this isn't
implemented in the selfsign plugin.
Also use the new type argument in x509.load_certificate(). Certificates
are coming out of LDAP as binary instead of base64-encoding.
The pyOpenSSL PKCS#10 parser doesn't support attributes so we can't identify
requests with subject alt names.
Subject alt names are only allowed if:
- the host for the alt name exists in IPA
- if binding as host principal, the host is in the services managedBy attr
The parsing bug was looking for the string 'version' expecting to find
the ACI version. This blew up with the attribute nsosversion. Use
the string 'version 3.0' instead.
The comparison bug appeared if neither ACI had a targetattr attribute.
It was trying to create a set out of a None which is illegal. If an
ACI doesn't have any targetattrs then return () instead.
This modifies the original patch by including a unit test, handling floats
when passed as unicode, and handling large magnitude values beyond maxint.
The INT parameter class was not respecting any radix prefix (e.g. 0x) the user
may have supplied. This patch implements _convert_scalar method for the Int
class so that we can pass the special radix base of zero to the int constructor
telling it to determine the radix from the prefix (if present).
Signed-off-by: John Dennis <jdennis@redhat.com>
If plugin fails to load log the traceback
If a plugin fails to load due to some kind of error it would be nice
if the error log contained the traceback so you can examine what went
wrong rather than being left blind as to why it failed to load.
If an exception is not handled here then the context isn't destroyed
leaving at least an LDAP connection dangling. This means the next time
this thread/process tries to handle a connection it will fail because
a context already exists.
This introduces 2 new params: --setattr and --addattr
Both take a name/value pair, ala:
ipa user-mod --setattr=postalcode=20601 jsmith
--setattr replaces or sets the current attribute to the value
--addattr adds the value to an attribute (or sets a new attribute)
OptionsParser allows multiple versions of this, so you can have multiple
setattr and addattr, either for the same attribute or for different
attributes.
ipa user-mod --addattr=postalcode=20601 --addattr=postalcode=30330 jsmith
Values are silent dropped if either of these on an existing param:
ipa user-mod --setattr=givenname=Jerry jsmith
Is a no-op.
