[Pki-users] Uniqueness of Subject Name issue

[Vesselin Kolev]

Thank you for the direct and clear answer, Fraser!

I do understand the reason why it is possible to have more than one
certificate with the same subjectName. But sometimes there are specific
requirements for the client. I will implement a constraint and try to
solve the problem it that way.

Best regards,

Veselin


On 04/02/2017 03:23 PM, Fraser Tweedale wrote:
> On Sat, Apr 01, 2017 at 05:17:42PM -0700, Vesselin Kolev wrote:
>> Hello,
>>
>> I installed the last version of DogTag but I have a problem with the
>> uniqueness of the Subject Name. By default I can issue more than one
>> certificate with the same Subject Name. The problem becomes even worst
>> when I use a profile based on directory authentication. So it looks that
>> anyone with proper credentials can issue countless number of certificate
>> with the same subject.
>>
>> Since is it a fresh installation and only the LDAP authenticator and
>> publisher are configured I doubt it is an error related to any
>> intervention to the certificate profiles. On the other side I can't fine
>> in the documentation (even in the on of Red Hat Certificate Server) this
>> discussed in any details.
>>
>> Do I do anything wrong or it is expected? Or if it is by default how
>> could I make it possible to limit the users using the automatic
>> enrolling to be able to have only one certificate?
>>
>> Thank you very much in advance for your answer.
>>
>> Best regards,
>>
>> Veselin Kolev
>>
> Hi Veselin,
>
> In general, it does not make sense to limit a subject to one
> certificate.  There are many reasons:
>
> - different certs for different purposes for same subject
>
> - certificates with different keys (or key types) for same subject
>
> - the need for an "overlap" between certs that are soon to expire,
>   and the replacement
>
> If you really do need to limit number of certs issued per subject,
> you could write profile constraint components to enforce that.  But
> they do not exist already, and we are unlikely to implement them.
>
> Thanks,
> Fraser