I am looking for a way to add extra, custom data in a SSL server certificate issued by a standard CA. Is this possible?

I want to get a SSL server certificate issued by a standard CA, so that it'll be accepted by standard browsers. However, I have a small amount of extra data that will be used by my private application that I'd also like to have included in the certificate. I'm looking for a way to include it in the certificate, in a way that standard browsers will ignore and (critically) that the CA won't strip out.

Is there a field or place where I can store arbitrary data, without it being stripped out by public CAs?

Maybe the otherName part of subjectAltName: will it be preserved by any standard CA? Should I be looking at a custom x509 extension?

The critical requirement is that for this to be not stripped out or modified by the CA. I need there to exist at least one CA that's trusted by major browsers, and won't strip out this custom data. I know that some fields of the certificate signing request (CSR) are filtered or stripped out by CAs, but I haven't been able to find documentation on which ones (if any) allow arbitrary data and will be preserved from the CSR into the final cert.

This question is related, but not the same: it doesn't have the requirement that the certificate be signed by a CA that's trusted by modern browsers. Also, I've found lots of information about how to add custom extensions to a x509 CSR, but that's not what I'm looking for; that doesn't tell me which extension to stuff the data into (which extension won't be stripped by major CAs). I know how to create a CSR containing custom data, but I don't know which fields of the CSR will get copied unmodified into the final server cert. I'm also not looking for a solution that involves running my own CA: I want the server cert to be accepted by standard browsers. This question also looks similar, but I don't see a clear answer there.

  • 3
    Hm. Feels like this might go against the (implicit) CA promise of being a reliable notary public. Because that would require them to both understand and verify the data they are signing for you. But if you use your own semantics then that is impossible for them. -- Of course they could still sign it. And CAs have been signing things for years that they had no way of checking and/or were absurd (e.g. arbitrary, externally unresolvable internal DNS names). -- I think your own sub-CA might be the way to go. Or maybe mapping your data onto valid (sub)domain-names. And then getting certs for those. Jun 19 '15 at 6:12
  • 2
    Additionally to what @StackzOfZtuff sayed: AFAIK CAs usually only take some data from the CSR which are relevant and ignore everything else, at least for the inexpensive plans. If you offer enough money, they still sign what you want, because they sell.
    – sebix
    Jun 19 '15 at 20:18

Well, I would contact CAs to ask if they would do it. They could do it, and maybe are willing to do it if you pay enough. Any non-critical fields that broswers do not understand will be ignored and could be added by the CA. The question is if they would do it and that only can be answered by them.

Some CPS even mention the possibility of adding non critical extensions (and thos can be private) and NOT adding, of course, critical private extensions (https://www.digicert.com/docs/cps/DigiCert_CP_v409-1-June-2015-signed.pdf - 7.1.2). Its just a matter of wanting to do it.

Issuer CAs shall use certificate extensions in accordance with applicable industry standards, including RFC 3280/5280. Issuer CAs shall not issue certificates with a critical private extension.

But probably the right way to do what you want is using Attribute Certificates. You could have a Attribute Certificate Issuer that you control and issue ACs to your SSL cert giving to it the extra attributes you need and only you understand. TLS has support to providing those ACs to your client or you could send those latter on using the already created SSL tunnel, and those could be interpreted by the client as needed.

  • Thanks! Unfortunately, I don't think attribute certs will meet my needs. I realize I didn't state this in the question (and should have), but the reason I wanted to add information into the SSL cert was to establish that the owner of the cert added/approved that information. With an attribute cert, there's no such binding: I can create an attribute cert for Google.com and put some information in it and sign it myself. So with attribute certs there's not a clear way to ensure that the owner of the SSL cert supplied/approved that extra information.
    – D.W.
    Jan 7 '16 at 19:49
  • I guess the other option is: instead of signing the attribute cert myself, if a trusted CA would issue an attribute cert, that might satisfy the requirement. That raises the question: Do any of the standard CAs (the ones trusted by browsers) issue attribute certs?
    – D.W.
    Jan 7 '16 at 19:57
  • I was thinking about the scenario, and looks like you want the subject of the certificate to declare something and proof he agrees with that info. I don´t see why just signing this extra data in any standard format (even PKCS#1) and send it by the SSL tunel would not fit your need that "the owner of the cert added/approved that information". In the other hand, it is not true that this info in a cert or AC is there because the subject agrees with it. The CA has the power to put it even if the subject does not asks it.
    – CristianTM
    Jan 8 '16 at 10:58
  • I would check if you need that "the owner of the cert added/approved that information" or do you need that "a CA says that the owner added/approved that information"?
    – CristianTM
    Jan 8 '16 at 10:59
  • Thanks. The real reason is that I'd like the server to be able to declare some additional information, and have it compose well with Certificate Transparency (I want it to appear in the public CT logs, which contain a log of the server cert, so the way to achieve that is to have the information in the server's cert). Signed/approved by the owner would be sufficient; a trusted CA says the owner added/approved that information would also be sufficient. I realize the real reason might be a distraction, and I figured others might well have other reasons to want extra info in the server cert.
    – D.W.
    Jan 8 '16 at 16:35

You asked:

Maybe the otherName part of subjectAltName?

No, not there. The Subject Alt Name (SAN) field is read by browsers and can be used to do Man in the Middle (MITM) attacks, so CAs should not allow custom (and non-publicly verifiable) data in the SAN fields.

I would point you to RFC 5280 that defines the X.509 certificate standard, specifically Section 4.2 Certificate Extensions. I'm not seeing any standard extension that allows general text, but the following expert is interesting (emphasis mine):

The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities. Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. The following sections present recommended extensions used within Internet certificates and standard locations for information. Communities may elect to use additional extensions

You said:

I know how to create a CSR containing custom data, but I don't know which fields of the CSR will get copied unmodified into the final server cert.

Nobody on this site can answer that for you. According to RFC 4210, a CA is allowed to modify non-critical extensions at will (and return the cert with the grantedWithMods PKIStatus). So as mentioned in comments, this is something that you will have to negotiate with a specific CA.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.