When I parse a certificate's subject or issuer, I need to know which X500Principal it uses. A cert can use RFC2253, RFC1779 or any other format as its X500Principal. If I choose the wrong X500Principal, I will get this result:
Subject:{
ST:"l_��"
C:"CN"
OU:"b�g/��"
CN:"N-V�epcn.cn"
L:"SWN�"
O:"l_�ϐ�[�y�b�g �PQlS�"
}
So, how can I make suer that which X500Principal a cert uses.
This sounds like a programming question and not a Let's Encrypt or ACME question. Maybe stackoverflow.com is a better place to ask it.
5 Likes
I've already done that, thank you anyway.
1 Like
OK，I can give a compromise solution, if anyone can give me a better solution, please reply and point out corrections!
First, when I get a cert, I use RFC2253 to parse the subject and the issuer, because most of the certificates now use RFC2253.
Then I use jchardet to find the encoding format of the subject's specific content.
According to RFC2253, if there is an encoding format other than UTF-8, I will use RFC1779 to parse the subject. RFC1779 has no requirement on the encoding format, and RFC2253 requires that the encoding format must be UTF-8.
And If the encoding format is UTF-8, then I will decode the info. If I find the '�' or ohther wrong code in the result string, I will also use RFC1779 to parse.
If I find '�' or ohther wrong code in the result string parsing by RFC1779, I will throw exception.
I know this is a simple and stupid solution, hopefully someone will come up with a better solution.
You can look to see if any java ACME clients or projects do this. See ACME Client Implementations - Let's Encrypt
5 Likes
I looked very briefly at the documentation about this and I don't think it's a matter of different certificates being different, I think it's a matter of what string encoding your application or environment uses. (I think if you choose the right setting, your code will work with any valid input certificate.) While it's true that ASN.1 has different string types available, I think the Java library is already translating them to a specified string encoding. I suggest that you use the CANONICAL version and I think that is likely to work for you in general.
If I've misunderstood what's going on, then I would unfortunately join the suggestion to ask on a Java-related forum because this specific concept and interface isn't very relevant to Let's Encrypt in particular (nor are many people on this forum likely to be familiar with it!).
Edit: but maybe you are getting different output based on what ASN.1 string type appears in the certificate? ... which isn't impossible. To see if this is the case, try openssl asn1parse -in filename.pem on different certificate files if they appear to have different behavior, and see if you can find a different data type in the subject or issuer.
6 Likes
OK，I will see， thank you for your advice.
1 Like
OK，I will try， thank you for your advice.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.