I purchased a Comodo Code Signing Certificate, and when I select that in my Metro app, and build, I get
Error 4 File content does not conform to specified schema. The 'Publisher' attribute is invalid - The value 'CN=Falafel Software Inc, O=Falafel Software Inc, STREET="512 Capitola Ave,", L=Capitola, S=CA, PostalCode=95010, C=US' is invalid according to its datatype 'http://schemas.microsoft.com/appx/2010/manifest:ST_Publisher' - The Pattern constraint failed.
C:\Users\jwaters\documents\visual studio 11\Projects\App1\App1\bin\Debug\AppxManifest.xml
10 57 App1
I found this more detailed message
'CN=Falafel Software Inc, O=Falafel Software Inc, STREET="512 Capitola Ave,", L=Capitola, S=CA, PostalCode=95010, C=US' violates pattern constraint of '(CN|L|O|OU|E|C|S|STREET|T|G|I|SN|DC|SERIALNUMBER|(OID\.(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))+))=(([^,+="<>#;])+|".*")(, ((CN|L|O|OU|E|C|S|STREET|T|G|I|SN|DC|SERIALNUMBER|(OID\.(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))+))=(([^,+="<>#;])+|".*")))*'. The attribute 'Publisher' with value 'CN=Falafel Software Inc, O=Falafel Software Inc, STREET="512 Capitola Ave,", L=Capitola, S=CA, PostalCode=95010, C=US' failed to parse.
It looks like the regexp doesn't understand PostalCode, which is in my certificate's Subject.
Is there any way to get around this?
Related
I have a Windows service that processes Certificate Signing Requests to make Certificates. It also makes self signed certificates (Certificate Authorities) on request by Windows users. In either case, I want to put the user account name (the NT Account string like 'domain\user') from the user who made the request to make the certificate in the finished certificate so that it is straightforward to track who created what.
Where is the best place to stick a user account string in a certificate? The first thing that came to mind is a custom extension. Does that make the most sense? Or perhaps an alternate field in the subject? I do not know if this is at all a common practice.
If you aren't committed to using the NT Account format, you could consider the emailAddress attribute in the certificate subjectName. Simply change Test\Bloggs to bloggs#test.
There is also the pseudonym attribute that could be used. However, while OpenSSL displays this attribute's name correctly, Windows shows it as 2.5.4.65 which may not be what you want.
In theory, the subjectAltName extension could also be used to store this. There is a otherName field, that could be used. However, OpenSSL displays a certificate as follows:
X509v3 Subject Alternative Name:
DNS:test.example.org, othername:<unsupported>
While Windows displays:
DNS Name=test.example.org
Other Name:
1.3.6.1.4.1.1=0c 0b 54 45 53 54 5c 42 6c 6f 67 67 73
Obviously, neither are any good to you.
Therefore, be pragmatic - either use the pseudonym and live with the way Windows displays it, or be even more pragmatic and hijack the OrgnaizationalUnitName (OU) attribute and use that. You can have multiple OUs therefore there wouldn't be a need to sacrifice any current OUs you may have. Digicert, Microsoft and Verisign (and no doubt, others) use the OU as an additional text field without any harm. It may not be 100% standard compliant, but it works.
If you do go down the latter route and you are using name constraints, make sure that this additional OU is first in the list when creating your signing request. That is, it doesn't break the order of the name constraint.
Is there any way to verify the OpenSSL signature using only {signature,hashed message} pair, skipping the original file to be presented for verification?
I need to verify the signature with only {signature,hashed message} pair remotely so using the original file is cumbersome specially when its very large.
Is there any way to verify the OpenSSL signature using only hash value and without needing the original file?
Yes, but there are strings attached.
The scheme which requires the original message to be presented to the verifying function is a Signature Scheme with Appendix (SSA). A scheme like the old PKCS #1.0 signing is an example of it.
The scheme which does not require the original message is a Signature Scheme with Recovery (PSSR). In a PSSR, the encoded message is part of the signature and masked. A scheme like the new PKCS #2.0 PSSR signing is an example of it.
There are no schemes that take just a hash, as far as I know. You have to have the {message,signature} pair. Allowing the message to be disgorged from the signing or verification can be a security violation.
OpenSSL provides both of them, as does most other security libraries, like Botan, Crypto++, NSS, etc.
Also see RSA signature on TLS on Information Security Stack Exchange.
I have been trying to verify the signature with hash value remotely so using the original file is cumbersome specially when its very large.
That's the insecure thing signature schemes want to avoid....
Somebody in my company is being subject to phishing. My first suggestion was just to change the password. However after awhile I received a fake mail from her address again.
Looking at the raw source of the email I found that there is another person's email in X-Sender-ID and I'm wondering who that might be. Is that the person who sent the email or can it be an account that has been hijacked? (I replaced the email with "somebody#host.com")
X-Virus-Scanned: OK
Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: somebody-AT-host.com) with ESMTPA id DF2788019C;
Fri, 21 Nov 2014 07:54:42 -0500 (EST)
X-Sender-Id: somebody#host.com
Received: from smtp.emailsrvr.com ([UNAVAILABLE]. [2.133.148.211])
by 0.0.0.0:587 (trex/5.3.2);
Fri, 21 Nov 2014 12:54:46 GMT
What is X-Sender-ID? And what is the email it contains?
My deliberations are based on this RFC which describes the Privacy Enhancement for Emails which you are obviously using.
Basically it says about the X-Sender-ID:
[...] encapsulated header field, required for all
privacy-enhanced messages, identifies a message's sender and provides
the sender's IK identification component.
What does this mean?
First of all you have to check if the mail is properly signed. If thats the case you can be sure that somebody#host.com has a certificate. And you can be sure that the mail you received has been sent from this mail address.
I can't tell you the consequences which result out of this fact as I don't know how your company is deploying the certificates etc. ... the mail address/certificate could also have been hacked and thereby abused.
I hope this helps you for your further research.
While #LMF's answer is useful technical information, I'd like to offer a possible alternative explanation.
Spammers who are not familiar with e-mail (and PHP programmers with no other malicious intent) tend to succumb to cargo cult programming when it comes to email headers. In other words, if there is something they don't understand, they might think it does something useful, and include it in their message template.
Without knowledge about your email infrastructure, or other messages of yours to compare to, I would simply assume everything below the top-most Received: header is forged, and basically without meaning.
If you have a system which runs something called trex (maybe this one?) and it really manages to write a Received: header like that, I might be wrong. The format needlessly deviates from the de-facto standard Sendmail template in a few places, but it's not technically wrong (the format is basically free-form, but introducing ad-hoc syntax makes it harder to guess what the fields mean).
Again, more information about what your typical email (and your correspondent's typical mail) looks like, this is heavy on speculation.
The x-sender-id, along with the x-recipient-id are used to specify which interchange key was used in the broadcast of the message.
X-Sender-ID entity_id : issuing_authority : version
X-Recipient-ID entity_id : issuing_authority : version
The first field contains the identity of the sender or receiver. The first field is mandatory, must be unique, and must be formatted as user#host whereas the host is a fully qualified host address.
The second identifies the name of the authority which issued the interchange key.
The third field specifies the specific type of interchange key which was used. This is represented by an alphanumeric string defined by the issuing authority to label and organize the numerous interchange keys issued by that authority. It is recommmended that they use a timestamp but is not always the case.
If the field values of the x-sender-id second and third field are identical to that of the x-recipient-id they may be only listed in the field which is defined last.
Further Reading
"Distributed Computing & Cryptography: Proceedings of a DIMACS Workshop"
In our application we generate certificates for internal entities like platform and user. Our internal entities are identified by custom DNs:
Platform DN: p=platformName
User DN: cn=userName,p=platformName
We tried to generate X.509 certificate for platform or user with popular tools like openssl, keytool, implementation of javax.security (BouncyCastle), e.g.:
keytool -genkey -dname "p=platformName" -alias platformName
However, those tools do not accept/recognize keyword "P" or require certain keywords like "CN" in certificate subject DN.
How to issue certificate to an entity with custom DN format?
Note: We do not need to have DNs containing standard keywords (CN, OU, etc.), because all certificates will be for internal use of our products (will not be validated by 3rd party or included in certificate chain).
We do not need to have DNs containing standard keywords (CN, OU, etc.)
How to issue certificate to an entity with custom DN format?
The attributes or fields displayed are a presentation level detail. There is no distinguished DN field per se. The fields used to form the DN are a mashup of other attributes and are arbitrarily chosen. The common ones are C, O, OU, CN, etc.
Attributes or fields like C, O, OU, CN have well known OIDs associated with them. There are other OIDs you can use that are recognized by tools. For example, the ITU's X.520 list hundreds of them. There are other standards that declare them too. For example, the email address attribute is from PKCS 9 and has an OID of 1.2.840.113549.1.9.1.
As Burhan Khalid stated, you can even add your own name/value pairs by making up OIDs (some hand waiving). However, other presentation tools won't know how to display them. That is, they won't know the "friendly name".
Because other tools don't recognize your OID for platform (or "p=..."), that's why you are getting ... those tools do not accept/recognize keyword "P". The tools don't know how to deal with your custom attributes.
I can only speak for openssl, as I am not familiar with other tools.
From the openssl docs
ASN1 OBJECT CONFIGURATION MODULE
This module has the name oid_section. The value of this variable
points to a section containing name value pairs of OIDs: the name is
the OID short and long name, the value is the numerical form of the
OID. Although some of the openssl utility sub commands already have
their own ASN1 OBJECT section functionality not all do. By using the
ASN1 OBJECT configuration module all the openssl utility sub commands
can see the new objects as well as any compliant applications.
So what you have to do is create these oids in /etc/openssl.conf or wherever the file is for your platform, then openssl will not give you the Subject attribute p has no known NID, skipped message, which I suspect is what you are getting now.
i am using
SignedCms.CheckSignature(certColl, true)
(with only one cert in certColl) to verify the signature of a pkcs-7 message. My problem is that i dont want to change the (public part of the) signers certificate on my server after the signer has renewed his certificate :-( The public key, issuer and subject are remaining unchanged after signer has renewed his certificate! So this has to work - at least in my opinion, even if i´m not a crypto-geek :-)
..but, unfortunately the .NET-Framework throws a Cryptographic Exception "Cannot find the original signer" like the stacktrace says exactly at:
SignerInfo.CheckSignature(X509Certificate2Collection extraStore, Boolean verifySignatureOnly)
This must be because the serial number of the signers certificate has changed and the SignerIdentifier property is readonly and set to IssuerAndSerialNumber.
Does anyone know how workaround this?
Or do i have to implement a "handmade" signature verifying with sth like: signedMessage.ComputeSignature(signer, false)?
Thanks in advance and happy programming,
Krile
For all interested on this issue:
Someone told me that this is due to the PKCS #7 specification, which states that the SubjectKeyIdentifier is always set to IssuerAndSerialNumber.