I am trying to generate a CSR for multiple sites with different top-level domains. These are the domains the client has asked we generate a single CSR for ( is the same for all):
site-name.org
site-name.com
www.site-name.org
www.site-name.com
learn.site-name.org
Is this possible?
Related
We have multiple types of certificates coming in from different sources. we need to differentiate whether it is a :
eIDAS QWAC
eIDAS QSEALC
Business
any other
if any openssl commands to check this
Question: Is there a technical explanation how client side code-signing can be used in enterprise enviroments with open source tools like signtool or openssl?
In my usecase, I want to create a hash of a code file and sent the hash on a seperate server. This server is just used for signing. On this server are also the certificates and private keys stored.
After the hash is signed, I want to transfer the signed hash back to the client and envelope the signed hash with the code file e.g. a .exe file.
In the "Mircosoft Code Signing Best Practices", it's also recommended to first create a hash of the data and then sign the hash value with a private key.
Unfortunately I can't find any further informations how to implement this with seperate steps, described as abow.
http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc
"In practice, using public-key algorithms to directly sign files is inefficient. Instead, typical code-signing procedures first create a cryptographic hash of the data in a file—also known as a digest—and then sign the hash value with a private key. The signed hash value is then used in the digital signature. The digital signature can be packaged with the data or transmitted separately. A separately transmitted digital signature is known as a detached signature."
I created private and public key using OpenSSL via the following commands
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key
The Question is:
Is creating DKIM key (private and public) using Openssl is safe, Is Openssl the preferred tool to do that.
Can I add the public.key to the domain’s DNS records (TXT).
Can I used private.key to setup DKIM Signing using Nodemailer.
please provide references in your answer
If the answer to above question is no which other tool should I use to do that? please provide the tool's commands that will generate the DKIM key (private and public)
Yes, you can, if your SMTP service allows you to provide an explicit key.
Some mail services require that they generate the key pairs and you only get the public key, they keep the private key stashed to use when signing e-mail. If your service allows you to provide them with the private key, then you are golden.
In fact, Amazon (AWS) requires you to do it this way if you are not using their "easy DKIM" methodology, so I've had to do this myself. Once you have generated those two files, you'll need to securely send the private key to your SMTP service, whatever that entails. Then you'll need to create the TXT record, containing the public portion of the key, for your DNS. It will look something like this:
"v=DKIM1; k=rsa; t=y; "
"n=AmazonSES DKIM public key valid 2020/6-2020/12; "
"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRx3I1vkqUygvM4oxOz"
"JUJfdV/QCvpqnOvtL2CuWuSgKcHH7CmVsb9MXGokHDXYRLgMyR8P2GD6peE"
"CdBwBd2vb643rX6saCb7uirI/NcllRsahtfa2Ier6sF8wBhbkWJRmfVhlvT"
"08BYW06MWS5uAkgdg7pFmpwbpTBkeMQMSLwIDAQAB"
The name of the TXT record in your DNS will either be decided by your SMTP service or it will allow you to specify it (called the selector). This is a field that will be placed into the signature header to match that particular e-mail header to the proper TXT record name. The name should have something indicating the version of the key, or the date on which it was generated, since that name will change when you refresh your key. An example would be "June2020.AmazonSES" for the key above. In this case the TXT record name should be:
June2020.AmazonSES._domainkey.example.com
You should never give the private key to multiple SMTP services. Generate a unique key for each, so there will be at least one TXT record per service. This allows you to update just the one if it was hacked without compromising any of the other services you use.
Also, use DMARC to get mail processors who get mail from you to send you error messages (to a mailbox you define in the _dmarc TXT record), so that you can decide when things are working well enough to take it out of test mode.
I am currently working on an architecture, where users can post content any server. To ensure the content has actually been posted by a certain user (and has not been altered after being posted), a signature is created using the private key of the author of the content, whose public key is accessible for everyone on a centralized repository.
Problem is, I have no control over how the content is actually stored on these servers. So I might transmit the content e.g. as a JSON object with all data being base64-encoded and the signature is created using a hash of this the base64-encoded content concatenated in a certain order:
{
"a": "b",
"c": "d",
"signature": "xyz"
}
with
signature := sign(PrivKey, hash(b + d);
Now the server will probably store the content of this in another way, e.g. a database. So maybe the encoding changes. Maybe a mysql_real_escape_string() is done in PHP so stuff gets lost. Now if one wants to check the signature there might be problems.
So usually when creating signatures you have a fixed encoding and a byte sequence (or string) with some kind of unambiguous delimiter - which is not the case here.
Hence the question: How to deal with signatures in this kinda scenario?
It is still required to have a specific message representation in bits or bytes to be able to sign it. There are two ways to do this:
just store the byte representation of the message and don't alter it afterwards (if the message is a string, first encode it with a well defined character encoding);
define a canonical representation of the message, you can either store the canonical representation the message directly or convert it in memory when you are updating the hash within your signature.
A canonical representation of a message is a special, unique representation of the data that somehow distinguishes it from all other possible messages; this may for instance also include sorting the entries of a table (as long as the order doesn't change the meaning of the table), removing whitespace etc.
XML encryption for instance contains canonicalization methods for XML encoding. Obviously it is not possible to define canonicalization for data that has no intrinsic structure. Another (even) more complicated canonical representation is DER for ASN.1 messages (e.g. X509 certificates themselves as well as within RSA signatures).
I think you're really asking two different questions:
How should data be signed?
I suggest using standard digital signature data format when possible, and "detached signatures" at other times. What this means in practice: PDF, Word, Excel and other file formats that provide for digital signatures should remain in those formats.
File formats that don't provide for digital signatures should be signed using a detached signature. The recommended standard for detached signatures is the .p7b file type–A PKCS#7 digital signature structure without the data. Here is an example of signing data with a detached signature from my company.
This means that the "Relying Party" -- the person downloading/receiving the information -- would download two files. The first is the original data file, unchanged. The second file will be the detached signature for the first.
Benefits The signed file formats that directly support digital signatures can have their signatures verified using the file's usual software app. Ie, the free Adobe PDF Reader app knows how to verify digitally signed PDFs. In the same way, MS Word know how to verify signed Word files.
And for the other file types, the associated detached signature file will guarantee to the recipient that the file was not modified since it was signed and who the signer was (depending on the trust issue, see below).
Re database storage -- you don't care how the data is stored on the different servers (database, file system, etc.) In any or all cases, the data should remain unchanged.
How to establish trust between the signer and the recipient
I suggest that the organization create its own root certificate. You can then put the certificate as a file on your SSL web site. (Your web site's SSL certificate should be from a CA, eg Comodo, VeriSign, etc.) The result is that people who trust your web site's SSL certificate can then trust your organizational certificate. And your signers' certificates should be chained to your organization's certificate, thus establishing trust for the recipients.
This method of creating a self-signed organizational certificate is low cost and provides a high level of trust. But relying parties will need to download and install your organization's certificate.
If that is not good, you can get certificates for your signers from a public Certificate Authority (CA), but that will drive up the cost by at least an order of magnitude due to the charges from the CA. My company, CoSign, supports all of these configurations.
My root certificates are stored as several files in ASN.1 format.
Assume I have a chained end entity certificate in the same format. How do I efficiently determine the root certificate of this certificate?
Currently I have to take a brute force approach which extracts the public key of the end entity certificate and validates that against all root certificates and the first match is considered the root certificate. Is this the right approach??
To find the issuer of a certificate, you should use the "Issuer DN" and match it with the "Subject DN" of the certificates in your CA store. This should reduce significantly the number of signature verification.
It is possible to have different CA certificates with the same "Subject DN" (with different public keys, validity dates, etc.), so your algorithm should be prepared to handle that. The "Subject Key Identifier" and "Authority Key Identifier" can also help to reduce the number of candidates.
Finding the issuing authority is only a small part of the "right approach" to validating certificates. I would advise you to look at part 6 of http://www.ietf.org/rfc/rfc5280.txt "Certification Path Validation". Some parts are most probably overkill (i.e. most things having to do with policies).