Subject: [pkix] RFC 2986 Guidance

From: daniel bryan <[email-masked]>
Date: Wed, 04 Nov 2015 18:26:23 +0000

Hello, I was reading RFC 2986 hoping to find guidance on an issue I
encountered and it's unclear to me if this issue is covered in the RFC. I
was hoping you all could share your thoughts on my situation defined below.

*Situation:* We use a web application that generates a CSR for an SSL
Certificate based solely off an inputted DN value. For example, we input
the value of C=US/O=GROUP/OU=Servers/CN=webappssl, and the web application
generated a CSR. We submitted the CSR to a Certificate Authority and it
signed the CSR based on the certificate template defaults for an
SSL cert.  Time passes, and our SSL cert expires. We intend to renew/obtain
a new SSL certificate for our webapp. We use the original DN mentioned
above, and it generates a CSR again.  We submit the CSR to our Certificate
Authority provider and the CA rejects the CSR saying that it has already
signed this CSR.

*Resolution: *I am attempting to figure out if I need to ask the vendor to
support unique CSR's even when the DN remains the same, or if I need to
contact the Certificate Authority team to ask them why they are blocking
duplicate CSRs. I would like to backup my request with definitive guidance
from an RFC.

*Question:* My question is, does RFC 2986
<https://tools.ietf.org/html/rfc2986>  or any other RFC provide guidance on
the situation above? I didn't notice anything during my initial scan, but I
wanted to check with you all.

Thanks,

--Dan

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 5 Nov 2015 06:23:46 +0900

Hi Dan,

in a Certification Authority not just the SubjectDN, but the combination 
SubjectDN + Serial has to be unique. That means you can have as many 
certificates with the same DN (also with overlapping validity periods) 
as long as they have different serial numbers (check RFC5280 and/or 
6818). So.. my suggestion is to tell your CA team to re-design their 
product to allow for your request to be honored.

In case that your CA Team is concerned about verifying that the request 
comes from the entity that originally requested the initial certificate 
(same DN), you can put the CSR into a CMS signed with the certificate 
that needs to be renewed (before it expires). This will provide proof 
that the same entity is requesting the certificate renewal (this could 
also be done when the certificate is expired, however that might require 
tweaking the crypto libraries to verify just the signature and not the 
certificate validity - a simple way to do that is to use the 
certificate's public key to verify the CMS signature directly.. but that 
is a bit of an hack - since you might not have the revocation 
information relevant to that certificate anymore.. so.. I never said 
that..officially! :-D)

Cheers,
Max

On 11/5/15 3:26 AM, daniel bryan wrote:
> encountered and it's unclear to me if this issue is covered in the 
> RFC. I was hoping you all could share your thoughts on my situation 
> defined below.
> *
> Situation:* We use a web application that generates a CSR for an SSL 
> Certificate based solely off an inputted DN value. For example, we 
> input the value of C=US/O=GROUP/OU=Servers/CN=webappssl, and the web 
> application generated a CSR. We submitted the CSR to a Certificate 
> Authority and it signed the CSR based on the certificate template 
> defaults for an SSL cert.  Time passes, and our SSL cert expires. We 
> intend to renew/obtain a new SSL certificate for our webapp. We use 
> the original DN mentioned above, and it generates a CSR again.  We 
> submit the CSR to our Certificate Authority provider and the CA 
> rejects the CSR saying that it has already signed this CSR.
>
> *Resolution: *I am attempting to figure out if I need to ask the 
> vendor to support unique CSR's even when the DN remains the same, or 
> if I need to contact the Certificate Authority team to ask them why 
> they are blocking duplicate CSRs. I would like to backup my request 
> with definitive guidance from an RFC.
>
> <https://tools.ietf.org/html/rfc2986> or any other RFC provide 
> guidance on the situation above? I didn't notice anything during my 
> initial scan, but I wanted to check with you all.
>
> Thanks,
>
> --Dan
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 5 Nov 2015 03:55:38 +0000

daniel bryan <[email-masked]> writes:

>My question is, does RFC 2986  or any other RFC provide guidance on the 
>situation above? I didn't notice anything during my initial scan, but I 

RFC 2986, a.k.a. PKCS #10, is just a format for bagging up cert request
data, it doesn't say anything about how a CA responds to it.  For that 
you need a higher-level protocol that wraps PKCS #10 and tells the CA what
you want done with it.  Typically you need to differentitate between an
initial request for a new cert and an update/renewal request, it looks like
you're trying to perform a renewal and the CA doesn't know it's just a 
request to renew an existing cert.

Peter.