I'm writing validation of SSL certificates and I'd like to know the format of certificate names with wildcards. From the RFC 2818:
Names may contain the wildcard character * which is considered to
match any single domain name component or component fragment. E.g.,
.a.com matches foo.a.com but not bar.foo.a.com. f.com matches foo.com but not bar.com.
Is it possible for the wildcard character to appear in the middle of the name? Also can I use a few of them in one name?
hello.*.a.com
*.*.a.com
I understand that it may not be practically useful, but I want to know what is technically possible.
I recommend you use the newer RFC 6125 instead of RFC 2818. This RFC make wildcard handling more clear. Essentially it means:
Only left-most labels, i.e. *.example.com but not www.*.com. This implicitly excludes multiple wildcards like *.*.example.com.
A wildcard label can be matched only against a single label, i.e. *.example.com will match www.example.com but not sub.www.example.com.
If the wildcard is not the full label (i.e. w*.example.com) it should not occur inside IDNA labels.
That's about what is implemented in the browsers today. Apart from that you'll find more restrictions like no wildcards for top-level and second-level (i.e. no * or *.com) and sometimes more restrictions like no wildcards for *.co.uk.
Also have a look at CAB Baseline Requirements, section 3.2.2.6.
Related
Official Documentation reports that link:
Rule matches requests from a list of sources that perform a list of operations subject to a list of conditions. A match occurs when at least one source, one operation and all conditions matches the request. An empty rule is always matched. Any string field in the rule supports Exact, Prefix, Suffix and Presence match:
Exact match: “abc” will match on value “abc”.
Prefix match: “abc*” will match on value “abc” and “abcd”.
Suffix match: “*abc” will match on value “abc” and “xabc”.
Presence match: “*” will match when value is not empty.
Does it mean that I can just apply * at beginning or end, so these kind of paths will not work ?
- operation:
methods: ["POST"]
paths: ["/example-service/test/*/operation"]
It sounds a limitation, isn't it?
It sounds a limitation, isn't it?
Yes, the path like this /example-service/test/*/operation is currently not supported.
You can use wildcard only at the start, end or whole string. You cannot use many wildcards or inside the string.
On the github you can find the issueSupport regex for ServiceRole spec.rules.paths, but it is currently open. The last sentence:
Is there any update for this feature? The support for /foo/id/*/bar would be a great plus.
Unfortunately, such use is not supported at the moment, though this may change in the future. Look also at this github issue and this question.
For the possible workaround see this github topic.
I have difficulties to understand the ordering of the attributes (AttributeTypeAndValue) in the RDN (RelativeDistinguishedName).
Here are the relevant ASN.1 definitions (taken from www.in2eps.com):
TBSCertificate
TBSCertificate ::= SEQUENCE {
[...]
subject Name,
[...]
}
Name
Name ::= CHOICE {
rdnSequence RDNSequence
}
RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1 .. MAX) OF AttributeTypeAndValue
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue
}
AttributeType
AttributeType ::= OBJECT IDENTIFIER
AttributeValue
AttributeValue ::= ANY -- DEFINED BY AttributeType
If I create a CSR containing "/CN=CommonNameX/O=OrganizationX/..." (in this specific order), how does a CA constructs a certificate out of this?
How will the certificate be constructed when setting the subject to ".../O=OrganizationX/CN=CommonNameX/" (same in reversed order)?
As far as I know the ordering of the RDN attributes is important when verifying certificate chains. Therefore, I assume there must by some detailed specification available?
More importantly, I would also like to know if there are different CAs using different orderings. If so, can someone point out some CAs?
EDIT:
After reading the first answers, I realized that I was asking for something very different than intended. To cut it short: the intended question was, if the ordering of the elements in the sequence of RDNs is important.
Sorry for the confusion, I will rectify the title of the question afterwards...
If I create a CSR containing "/CN=CommonNameX/O=OrganizationX/..." (in this specific order), how does a CA constructs a certificate out of this?
A decent CA should practically ignore the DN submitted in the CSR and build the Subject DN from information it has verified. That is, usually, they'll put their own Country, Organization, OU (and so on) depending on their CA policies. They'll change the CN to be that of the host you've applied for (for example, or whatever else is relevant from the application process depending on the type of certificate). What's in the CSR is useful to keep track of the identity of the public key submitted during the application process, but it's at best useful for administrative purposes.
As far as I know the ordering of the RDN attributes is important when verifying certificate chains. Therefore, I assume there must by some detailed specification available?
Yes, the order matters RDNSequence is indeed a SEQUENCE OF RelativeDistinguishedName. Each RDN is itself a set (which is unordered) of AVAs (Attribute Value Assertion / AttributeTypeAndValue): SET SIZE (1 .. MAX) OF AttributeTypeAndValue.
The matching rules for each RDN content (the set of AVAs) and each DN (the sequence of RDNs) is defined in RFC 5280:
Two naming attributes match if the attribute types are the same and
the values of the attributes are an exact match after processing with
the string preparation algorithm. Two relative distinguished names
RDN1 and RDN2 match if they have the same number of naming attributes
and for each naming attribute in RDN1 there is a matching naming
attribute in RDN2. Two distinguished names DN1 and DN2 match if they
have the same number of RDNs, for each RDN in DN1 there is a matching
RDN in DN2, and the matching RDNs appear in the same order in both
DNs. A distinguished name DN1 is within the subtree defined by the
distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.
Essentially, RDNs in a DN need to be in the correct order (SEQUENCE is ordered), but the order of AVAs don't (SET is not ordered): "Two relative distinguished names RDN1 and RDN2 match if they have the same number of naming attributes and for each naming attribute in RDN1 there is a matching naming attribute in RDN2."
In reality, most CAs only use one attribute value pair per RDN. I wouldn't be surprised if a number of implementations (not necessarily part of the SSL/TLS stack, but say, authentication/authorisation layers on top of it) that rely on text serialisation (RFC 2253 for example) would get confused by multiple AVAs (more specifically by the fact their order doesn't matter within each RDN, so you could have two distinct text serializations that are in fact equivalent).
(As an addendum to #CryptoGuy's answer some background on DN comparison)
The basic IETF specification on Internet X.509 Public Key Infrastructure Certificates is RFC 5280.
Rules for comparing distinguished names are specified in Section 7.1. They are:
Two distinguished names DN1 and DN2 match if they
have the same number of RDNs, for each RDN in DN1 there is a matching
RDN in DN2, and the matching RDNs appear in the same order in both
DNs.
Two relative distinguished names
RDN1 and RDN2 match if they have the same number of naming attributes
and for each naming attribute in RDN1 there is a matching naming
attribute in RDN2. (Note: There is no requirement on the order of appearance of the naming attributes!)
Two naming attributes match if the attribute types are the same and
the values of the attributes are an exact match after processing with
the string preparation algorithm.
Thus, two DNs have to be considered equal even if they differ in the order of naming attributes in some matching relative distinguished name.
Unfortunately there is a relevant number of programs in the wild which fail in this respect. To play it safe, therefore, simply put but one naming attribute into each RDN.
Concerning the tree structure mentioned by #CryptoGuy in his answer, it a bit more formally is defined as follows in the same section 7.1:
A distinguished name DN1 is within the subtree defined by the
distinguished name DN2 if DN1 contains at least as many RDNs as DN2,
and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.
It is expected behavior. RDN attributes are parts of X.500 distinguished names, which is a tree. The tree is built starting from root node and by adding nested subnodes. For example, a subject CN=John Wayne, OU=IT Department, DC=contoso, DC=com would be built as follows:
Root/top-level node: com
Sub node within root node/domain: contoso
Organization Unit within domain: IT Department
Common name, end entity, or principal: John Wayne
this is why RDNs are placed in reverse order. For convenience, certificate viewers reverse RDN attribute ordering where principal name is displayed first.
If I create a CSR containing "/CN=CommonNameX/O=OrganizationX/..." (in this specific order), how does a CA constructs a certificate out of this?
CA will not change the RDN attribute order in the subject name because they are already reversed in the certificate request. You can open generated request file in any ASN.1 viewer to get actual order of RDN attributes in binary request.
More importantly, I would also like to know if there are different CAs using different orderings. If so, can someone point me to some available CAs?
all CAs I worked with behave as described above (use reverse ordering when encoding X.500 names).
edit: representation of distinguished names is defined in [RFC1779]
edit2 (to RDN sequence order importance question): as it was already said, it is important. When CA signs certificate, it shall place RDNs in the Issuer field in the same order as they appear in its own certificate's Subject field.
The primary answer to this question is accurate except for the ordering of RDNs in DER-encoded (X.690) ASN.1.
DER encoding of SET OF ASN.1 constructed types means that you HAVE TO sort all Attribute-Type-And-Value items comparing their DER encodings (shorter DER encodings have to be zero-filled while comparing).
Source: ITU-T X.690 11.6 'Set-of components'.
Please note that the vast majority of X.509v3 certificates is indeed DER-encoded today.
Is there any limit for subject alternative names in X.509? Also are there any rules for the SAN?
1. Also are there any rules for the SAN?
RFC5280 specifies Subject Alternative Names as
SubjectAltName ::= GeneralNames
whereby GeneralNames are
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
So, look the up the 'rules' for a GeneralName in the rfc (page 37).
2. Is there any limit for subject alternative names in X.509?
As stated in the same rfc in chapter Appendix B. ASN.1 Notes:
The SIZE (1..MAX) construct constrains the sequence to have at least
one entry. MAX indicates that the upper bound is unspecified
The Subject Alternative Name extension is fully specified by RFC 5280 section 4.2.1.6.
Some rules or notes about the use of this extension include:
The subject name MAY be
carried in the subject field and/or the subjectAltName extension. Note that if any dNSName is present in the subjectAltName extension, then all DNS names should be included there, including those in the subject name field. See RFC 2818 for details.
If the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail address), then the
subject distinguished name MUST be empty (an empty sequence), and the
subjectAltName extension MUST be present and marked as critical.
Subject alternative names MAY be constrained in the same manner as
subject distinguished names using the name constraints extension. That is, the name constraints extension on a CA certificate can impose a name space within which all subject names (including alternative names) in
subsequent certificates in a certification path MUST be located.
If the subjectAltName extension is present, the sequence MUST contain
at least one entry. No upper bound is defined; implementations are free to choose an upper bound that suits their environment.
Unlike the subject field, conforming CAs MUST
NOT issue certificates with subjectAltNames containing empty
GeneralName fields.
The semantics of subject alternative names that include
wildcard characters are
not addressed by RFC 5280. However, RFC 6125 states "the wildcard character '*' SHOULD NOT be included in presented identifiers"
I need to match two ipaddress/hostname with a regular expression:
Like 20.20.20.20
should match with 20.20.20.20
should match with [http://20.20.20.20/abcd]
should not match with 20.20.20.200
should not match with [http://20.20.20.200/abcd]
should not match with [http://120.20.20.20/abcd]
should match with AB_20.20.20.20
should match with 20.20.20.20_AB
At present i am using something like this regular expression: "(.*[^(\w)]|^)20.20.20.20([^(\w)].*|$)"
But it is not working for the last two cases. As the "\w" is equal to [a-zA-Z0-9_]. Here I also want to eliminate the "_" underscore. I tried different combination but not able to succeed. Please help me with this regular expression.
(.*[_]|[^(\w)]|^)10.10.10.10([_]|[^(\w)].*|$)
I spent some more time on this.This regular expression seems to work.
I don't know which language you're using, but with Perl-like regular expressions you could use the following, shorter expression:
(?:\b|\D)20\.20\.20\.20(?:\b|\D)
This effectively says:
Match word boundary (\b, here: the start of the word) or a non-digit (\D).
Match IP address.
Match word boundary (\b, here: the end of the word) or a non-digit (\D).
Note 1: ?: causes the grouping (\b|\D) not to create a backreference, i.e. to store what it has found. You probably don't need the word boundaries/non-digits to be stored. If you actually need them stored, just remove the two ?:s.
Note 2: This might be nit-picking, but you need to escape the dots in the IP address part of the regular expression, otherwise you'd also match any other character at those positions. Using 20.20.20.20 instead of 20\.20\.20\.20, you might for example match a line carrying a timestamp when you're searching through a log file...
2012-07-18 20:20:20,20 INFO Application startup successful, IP=20.20.20.200
...even though you're looking for IP addresses and that particular one (20.20.20.200) explicitly shouldn't match, according to your question. Admittedly though, this example is quite an edge case.
I recently read some of : https://www.rfc-editor.org/rfc/rfc6570#section-1
And I found the following URL template examples :
GIVEN :
var="value";
x=1024;
path=/foo/bar;
{/var,x}/here /value/1024/here
{#path,x}/here #/foo/bar,1024/here
These seem contradictory.
In the first one, it appears that the / replaces ,
In the 2nd one, it appears that the , is kept .
Thus, I'm wondering wether there are inconsistencies in this particular RFC. I'm new to these RFC's so maybe I don't fully understand the culture behind how these develop.
There's no contradiction in those two examples. They illustrate the point that the rules for expanding an expression whose first character is / are different from the rules for expanding an expression whose first character is #. These alternative expansion rules are pretty much the entire point of having a variety of different magic leading characters -- which are called operators in the RFC.
The expression with the leading / is expanded according to a rule that says "each variable in the expression is replaced by its value, preceded by a / character". (I'm paraphrasing the real rule, which is described in section 3.2.6 of that RFC.) The expression with the leading # is expanded according to a rule that says "each variable in the expression is replaced by its value, with the first variable preceded by a # and subsequent variables preceded by a ,. (Again paraphrased, see section 3.2.4 for the real rule.)