I want to ask a thing about digital signing I am not very sure.
Instead of creating a self signed certificate to use to sign some (PDF) files, I wanted to take my SSL cert which have my data already verified.
But the question is: Can a SSL cert be used to digital sign files or is it incompatible in some manner?
EDIT: To clarify, this question is not about how to sign PDFs, is only about if a SSL cert can be used (or converted in any way) to sign files.
To support digital signing certificate must have digitalSignature option in it's keyUsage field (and codeSigning option in it's extendedKeyUsage field if your want to sign programs with it).
Signing may be done with existing tools or manually (java example, you are not asking for it, but this code snippet might be useful anyway):
byte[] bytesToSign = loadMyData();
KeyStore ks = KeyStore.getInstance("pkcs12", "SunJSSE");
ks.load(new FileInputStream("cert.p12"), "passwd1".toCharArray());
PrivateKey privateKey = (PrivateKey) ks.getKey("myalias", "passwd2".toCharArray());
Signature sig = Signature.getInstance("SHA1withRSA", ks.getProvider());
sig.initSign(privateKey);
sig.update(bytesToSign);
byte[] signature = sig.sign();
To make your own not self-signed certificate with openssl see this SO answer.
Also curious about signing PDF's - aren't separate hash sums of these files enough in your case?
edit: if you want any sign, not exactly X.509 sign by existing tools, you can extract RSA key from your cert and do signing without bothering about keyUsage field.
At the core, the certificate is just a normal RSA public key that's been signed by several authorities.
So yes, definitely possible.
Though I don't know of any easy-to-use widespread tools for the end-user for this.
Yes, you can sign and verify the signature of files using SSL certificates
Here is an example:
SSLCERT='/XXXX/ssl/certs/fqdn.pem'
SSLKEY='/XXXX/ssl/private_keys/fqdn.pem'
# You might not need to specify a CA
CACERTFILE='/XXXX/ssl/certs/ca.pem'
# File to sign
FILE='YYYYYYY'
# Signs, needs ${SSLKEY} and ${FILE}
openssl dgst -sha512 -sign ${SSLKEY} -out ${FILE}.sha512 ${FILE}
# Then transfer the following files to another server:
# - ${CACERTFILE}
# - ${SSLCERT}
# - ${FILE}
# - ${FILE}.sha512
# Check the certificate is valid
openssl verify -verbose -CAfile ${CACERTFILE} ${SSLCERT}
# Extract the pub key from the cert
openssl x509 -in ${SSLCERT} -pubkey -noout > ${SSLCERT}.pub
# Check the signature
openssl dgst -sha512 -verify ${SSLCERT}.pub -signature ${FILE}.sha512 ${FILE}
Related
I am trying to use the new SPM Collection signing utility found at https://github.com/apple/swift-package-collection-generator/tree/main/Sources/PackageCollectionSigner
But I honestly don't know how to get the necessary files.
Here is the definition:
USAGE: package-collection-sign <input-path> <output-path> <private-key-path> [<cert-chain-paths> ...] [--verbose]
ARGUMENTS:
<input-path> The path to the package collection file to be signed
<output-path> The path to write the signed package collection to
<private-key-path> The path to certificate's private key (PEM encoded)
<cert-chain-paths> Paths to all certificates (DER encoded) in the chain. The certificate used for signing must be first and the root
certificate last.
I understand the input-path and output-paths arguments but where do I get the PEM encoded private key and the DER encoded path chains?
Sorry if I am being naive, but this is just an area I have no experience with.
Any help about how I get/generate these files would be helpful.
thank you.
The private key you can generate yourself on the command line
openssl genrsa -out private.pem 2048
chmod 600 private.pem
Once you have the key, you will need to request a certificate that uses it. This can also be done on the command line:
openssl req -new -key private.pem -out signing.csr
Once you have that, you can go to developer.apple.com and click on the "Certificates, Identifiers and Profiles" section, then click on the "Certificates" tab. Click the blue plus button, choose the "Swift Package Collection Certificate" option and click Continue.
It will ask you to upload a CSR, so click Choose File and select the signing.csr file you just created. Download the generated certificate and rename it to signing.cer and you should be ready to go.
*Once you're done this, you can delete the signing.csr file.
New to using jose4j. I have found examples like this to set private key from cert:
JsonWebSignature jws = new JsonWebSignature();
PKCS8EncodedKeySpec spec =
new PKCS8EncodedKeySpec(keyBytes);
KeyFactory kf = KeyFactory.getInstance("RSA");
PrivateKey pk = kf.generatePrivate(spec);
jws.setKey(kf.generatePrivate(spec));
But I get this error message
java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format
I think it is because the cert was created as SHA256 instead of RSA. Here is how I was told the cert was created:
openssl req -x509 -sha256 -nodes -days 730 -newkey rsa:2048 -keyout private.key -out certificate_pub.crt
Does anyone have any examples of how I could sign JWT with a SHA256 cert?
With additional info, that private key file is PEM but NOT PKCS#8, as a modern version of OpenSSL should have created for req -newkey. And the difference between PEM and "DER" (binary) which standard Java requires is not just removing (and adding) the BEGIN and END lines.
Your simplest solution if OpenSSL is available is to convert both of these, without encrypting:
openssl pkcs8 -topk8 -nocrypt -outform der -in private.pem -out good.der
Then read good.der (use better name if you like) as bytes, and put that in PKCS8EncodedKeySpec and use it as you posted. Aside: you don't need to fiddle with DataInputStream, which isn't really intended for "plain old" bytes; java.nio.file.Files.readAllBytes can open, allocate, and read for you.
The next more complicated alternative is to convert to PKCS#8 but still PEM: same as about but omit -outform der (and use a file name that indicates PEM, to avoid confusion). Then in Java read that file as characters (with a Reader, usually BufferedReader, not a Stream), discard the BEGIN and END lines, concatenate all the lines between, and convert them from base64 to byte[]: in Java8 you have java.util.Base64, before that you can use javax.xml.bind.DatatypeConverter.
To read the file you have in standard Java is harder. You could read the PEM-armored PKCS#1 and convert to binary PKCS#1, then "wrap" the PKCS#1 into PKCS#8 by building the DER encoding, but that's a good bit more complicated than what you've demonstrated familiarity with. Or you could parse the PKCS#1 and use the components to construct your own implemenation of RSAPrivateCrtKey and use that directly (no factory), ditto.
The other alternative is to use the third-party library from http://www.BouncyCastle.org which has more flexible features for handling PEM files than standard Java. But you need to learn their API as well as the standard one, and if your program will run anywhere else you need to ensure BC is deployed with or as part of your program.
I need to make light weight PKC for that i want to delete x509 v3 extensions from the user certificate. May i use this openssl command to delete v3 extensions?
openssl x509 -in /usr/local/openca/var/openca/crypto/certs/E841B2655206FA6A3ADA.pem -noout -text -certopt no_extensions -out /usr/local/openca/var/openca/crypto/certs/ -out
E841B2655206FA6A3ADA_nov3ext.pem
or where should i make changes to generate x509 v1 certificate since it doesn't contain x509 extensions. could you please provide me a link for the reference.
thanks for your time.
Usually (well, virtually always really!) the signature does not just cover the distinguished name on the cert; but everything else as well (serial, expiry dates, etc).
So while it is not hard to cut down the certificate to size - it will instantly invalidate the signature by its issuer.
However - in some cases it is possible to do something else - and that is dispense/ignore the signature part of the cert completely; and just focus on the public key.
Use someting like
cat somecert.pem | openssl x509 -pubkey -nout
to get just the public key. So forego all of X509 and in essense no longer have a PKI. Just pairs of raw public keys and private keys.
Then in your application commit the fairly unforgivable gaffe of inventing your own crypto - and have the owner of that public key sign something like a NONCE with its private key; and validate the signature. E.g.
# the 'server' sends a nonce to the client
openssl rand -base64 128 > send-to-client
then on the client it is signed
cat msg-from-server | openssl pkeyutl -inkey privkey.pem -sign | base64 > send-to-server
and on the server we check this
cat msg-from-client | openssl pkeyutl -in pubkey-of-client.pem -verify
and take things form there. However unless you are a kick-ass cryptographer and protocol designer, schemes like this (and above certainly does!) are riddled with flaws and pitfalls.
But in theory it does let you use just a few 1000 bytes of RSA keys; or a few 100 bytes of Elliptic curve based keys.
On running:
openssl ca -in ${ALIAS}.csr -out user-cert.pem -keyfile cacert-private.pem -cert cacert.pem -passin pass:$PASSWD -config ${CONFIG}
I get:
The stateOrProvinceName field needed to be the same in the
CA certificate (Gloucestershire) and the request (Gloucestershire)
I've read the error a few times and I'm fairly sure the field is the same value in each case. I have found references to similar problems being caused by different encodings but I don't know how I should be specifying that and where.
This is the ${ALIAS}.csr:
-----BEGIN NEW CERTIFICATE REQUEST-----
MIICxzCCAa8CAQAwgYExCzAJBgNVBAYTAkdCMRgwFgYDVQQIEw9HbG91Y2VzdGVyc2hpcmUxEzAR
BgNVBAcTCkNoZWx0ZW5oYW0xHzAdBgNVBAoTFldhbnNkeWtlIEhvdXNlIExpbWl0ZWQxDjAMBgNV
BAsTBUZpemlvMRIwEAYDVQQDEwlsb2NhbGhvc3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDWvivt1JHiuaNeadOQJtxynQ4sSAR/peWgKd8g9UQgNM+H9QW4NlRE81+g63BdRqZT5YMm
J4K3upovQNlDRklevslgEYoTdQM4yBKV676Q4XDbM7Vk+rt04sqL5IgdsAUXODfMJvu81t3tOjFc
OGO7S+B+LEJ1+8qshLbuK2gBigfgcZtlbNgW6fCGik8ZsrKWl8W+NFbw1seS01INAipwCBasxaaj
/lINwWQVbQIG09+vEdwuHmmq5VIKlJqFcYNUTFBVojoJLfzyStZR2PfFUxp7R+t2YmVj6a48B7NA
lODnIlQDkAprECNMpCZoSP1QjrZgW1BgaVbT5OaWlVsPAgMBAAGgADANBgkqhkiG9w0BAQUFAAOC
AQEAvalFyJOgzmd1jcFlS5YoqiNgX1bm9nZ0/cFgj6cGL7R0Gqc9wu5QPakWRxa9c2UcI0m7p1lp
cygDvQTY23LEBhVcruymIGQG5DhDpXHeaBCbV3OWO6xowAjh+riQjvTNeVSXtP3jUNs5DaId0z+A
GXeb7dR96jhyj+soNYENoQseQLqLdAW4p0jdK1BraMJTc0ber0FBx1nOUXOEoTIJL9kL9cUWaCp3
7uYkonIPtVCCfS8KcgXxUsNMC41q/SkKDVB23PeCjnWgcyXxnSpx8n+AK7fwMgh+4TcZ5usmVujR
MNqk84hZpw8h1FIcmqRaWtaPWyv3EX8JH5LTnDe3eQ==
-----END NEW CERTIFICATE REQUEST-----
And cacert.pem:
-----BEGIN CERTIFICATE-----
MIIDQDCCAqmgAwIBAgIJAPj9mvMDl1K/MA0GCSqGSIb3DQEBBQUAMIG4MQswCQYD
VQQGEwJHQjEYMBYGA1UECAwPR2xvdWNlc3RlcnNoaXJlMRMwEQYDVQQHDApDaGVs
dGVuaGFtMR8wHQYDVQQKDBZXYW5zZHlrZSBIb3VzZSBMaW1pdGVkMQ4wDAYDVQQL
DAVGaXppbzESMBAGA1UEAwwJbG9jYWxob3N0MTUwMwYJKoZIhvcNAQkBFiZyaWNo
YXJkLm1pZHdpbnRlckB3YW5zZHlrZS1ob3VzZS5jby51azAeFw0xMTA4MDcyMTU4
NDBaFw0yMTA4MDQyMTU4NDBaMIG4MQswCQYDVQQGEwJHQjEYMBYGA1UECAwPR2xv
dWNlc3RlcnNoaXJlMRMwEQYDVQQHDApDaGVsdGVuaGFtMR8wHQYDVQQKDBZXYW5z
ZHlrZSBIb3VzZSBMaW1pdGVkMQ4wDAYDVQQLDAVGaXppbzESMBAGA1UEAwwJbG9j
YWxob3N0MTUwMwYJKoZIhvcNAQkBFiZyaWNoYXJkLm1pZHdpbnRlckB3YW5zZHlr
ZS1ob3VzZS5jby51azCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA03Y4hYdd
at3e3AB98s+E5wlxrvRL8RhJtRac0Jt0gXQy12ZYziFm3gryx0IG02srXluM+V3/
BPRRCLsnEnltfoi/fE0wM9MT0V1Ao9EXQ5t1E2rOzdoXUUdvovd6qvwG2L/DHCdL
kKjhokVR9TkFW/AWctBdWkb9qfFFTpDY4i0CAwEAAaNQME4wHQYDVR0OBBYEFHbG
d3+Lzax90slk65y1BYDgZ897MB8GA1UdIwQYMBaAFHbGd3+Lzax90slk65y1BYDg
Z897MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEArZ2yfTGJK3R+jRwP
FjaonDy1NVOt9tgjHfyh9YNQfyFSC7R987wFPcyydEqh8xg/Lb3WGwseDuzCBusw
jmVIqiUYBClHzkF3jG1766ltdlVVTOavVQgQMRBGMvpHVxcMH2RUNUyWH0XW+DH2
/uuRRpu4vX5sfEW75uEfORB9Mrg=
-----END CERTIFICATE-----
Any ideas? Thanks in advance.
You can also set the attributes as optional:
# For the CA policy
[policy_match]
countryName= optional
stateOrProvinceName= optional
organizationName= optional
organizationalUnitName= optional
commonName= supplied
emailAddress= optional
I have also run into this problem. Thanks to the replies above (mainly Francois), I discovered the source of the problem.
openssl is encoding using UTF8STRING and keytool (Java 6) is encoding with PRINTABLESTRING.
Worked around it by changing the openssl configuration so it matches keytool. In /usr/ssl/openssl.cnf change the "string_mask" setting to "pkix".
The previous posters already answered the question, but to make it easier, here is an example how to specify the encoding. Use the string_mask:
[ req ]
default_bits = 2048
default_md = rsa
prompt = no
string_mask = utf8only # <--------------
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
countryName = GB
stateOrProvinceName = Gloucestershire
localityName = Cheltenham
organizationName = Wansdyke House Limited
organizationalUnitName = Fizio
commonName = localhost
As shown by :
openssl asn1parse -in req.csr
the request DN strings are encoded as PRINTABLESTRING.
openssl asn1parse -in cacert.pem
shows the CA DN strings are encoded as UTF8STRING.
For a quick'n dirty hack, I suggest you change the encoding of strings in your request by replacing the encoding type for PRINTABLESTRING (0x13) by the type for UTF8STRING (0x0c), using your favorite hex editor.
You will have to convert your request in DER before poking it.
The offset of bytes to change can be found with :
openssl asn1parse -in csr |grep PRINTABLESTRING |awk -F":" '{print $1}'
Then try to sign again.
I just ran into this problem. The root cause is a mismatch between the values of string_mask in the client's and the CA's openssl.cnf. The easy fix is to modify the client's value to match what the CA expects, then regenerate the CSR. The hard fix is to edit the CA's value and start a fresh CA.
Promoting mbrownnyc's comment to an answer, as it was useful to me and deserves more attention.
I believe /usr/ssl/openssl.cnf contains a policy called policy_anything that contains the above setup. You can use it by utilizing the policy argument as follows:
openssl ca -policy policy_anything -days 365 -out /root/ca/certs/out.pem -in certreq.csr
How can I create a certificate using makecert with a 'Subject Alternative Name' field ?
You can add some fields eg, 'Enhanced Key Usage' with the -eku option and I've tried the -san option but makecert doesn't like it.
This is a self-signed certificate so any method that uses IIS to create something to send off to a CA won't be appropriate.
An even easier way is to use the New-SelfSignedCertificate PowerShell commandlet, which includes a SAN by default. In a single command you can create the certificate and add it to the store.
New-SelfSignedCertificate -DnsName localhost -CertStoreLocation cert:\LocalMachine\My
Note that you need to run PowerShell as an administrator.
Makecert doesn't appear to support SANs so I created a certificate with SANs for use with IIS using OpenSSL. Check out my blog post about it:
IIS 7 provides some easy to use wizards to create SSL certificates,
however not very powerful ones. What I needed to do was to create SSL
certificates that included a x.509 V3 extension, namely subject
alternative names, a.k.a SANs. What SANs do is allow the website
certificate to validate incoming requests by more than one URL domain
name. This is really important when the web server is running web
services such as WCF services and when other web services connect to
them over SSL connections as with service oriented architectures.
Unless special code is added to the web services to override the
default SSL validation handler routines, the common name (CN) of the
certificate MUST match the incoming request URL domain. So if the
request was made using an FQDN, the certificate must have the FQDN as
a CN or a SAN, a IP address or just a hostname will cause an SSL
validation error and the connection will fail.
SANs to the rescue… SANs support, among other things, DNS names and IP
addresses. So by creating the certificate with SANs of the server FQDN
and IP address, it increases the ways that other web services can
connect.
There are a number of tools that can generate certificates:
makecert.exe, keytool.exe (java), selfssl.exe and openssl.exe. In
addition, starting with Windows Vista and Server 2008 Microsoft added
the CertEnroll API which can also create certificates programmatically
either through COM interfaces.
OpenSSL ended up doing exactly what I needed it to do. The process was
fairly straight forward.
Construct an OpenSSL config file.
[req] distinguished_name = req_distinguished_name x509_extensions =
v3_req prompt = no [req_distinguished_name] C = US ST = VA L =
Somewhere O = MyOrg OU = MyOU CN = MyServerName [v3_req] keyUsage =
keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth
subjectAltName = #alt_names [alt_names] DNS.1 = MyServerName DNS.2 =
10.0.1.34 IP.1 = 10.0.1.34 IP.2 = 192.167.20.1
Create x509 request with OpenSSL
openssl.exe req -x509 -nodes -days 730 -newkey rsa:2048 -keyout
C:\cert.pem -out C:\cert.pem -config C:\PathToConfigFileAbove.txt
Create a PFX containing the keypair
openssl.exe pkcs12 -export -out C:\cert.pfx -in C:\cert.pem -name "My
Cert" -passout pass:mypassword
Import the PFX into IIS using the import link in the server
certificates area.
Bind the certificate to the IIS websites.
And viola, we know have a SSL certificate for IIS with SANs so we can
connect using multiple domain names without certificate validation
errors.
Source: Creating certificates with SANs using OpenSSL by Andy Arismeti, Thursday, September 1, 2011
Update
The certificate generated using the below makecert method does not work reliably in all browsers, because it does not actually generate a "Subject Alternative Name".
If you examine the certificate you will see that it does not actually have a Subject Alternative Name field, but instead specifies multiple CN in the Subject field.
E.g.
Subject:
CN = blah.foo.corp
CN = blah
Whereas a real "SAN" cert would have something like:
Subject Alternative Name:
DNS Name=blah.foo.corp
DNS Name=blah
To understand the differences and history between the "Subject" field with "Common Name" and the "Subject Alternative Name" field, I recommend reading The (soon to be) not-so Common Name.
So it appears that makecert cannot be used to generate a true "SAN" cert, and you will need to use other tools, such as openssl.
Original Answer:
At least with the version of makecert that comes with Visual Studio 2012, you can specify multiple subjects, simply by specifying a comma separated list -n "CN=domain1, CN=domain2"
E.g. (from the technet blog Makecert.exe SAN and Wildcard certificate)
makecert -r -pe -n "CN=*.fabrikam.com, CN=*.contoso.com" -b 01/01/2010 -e 01/01/2100 -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.3,1.3.6.1.5.5.7.3.4 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -len 2048