Password incorrect importing certificate on 2012 server - server

When i try to import certificate on server 2012 it say password incorrect.
I have check this post:
"The password you entered is incorrect" when importing .pfx files to Windows certificate store
And i exported:
openssl.exe pkcs12 -in 'C:\cert.p12' -out C:\key.pem And created the new cert: openssl.exe pkcs12 -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES -export -in 'C:\key.pem' -out 'C:\newcert.pfx' -name "newcert"
But when i try to import in server 2012 keep saying password incorrect.

The top answer in that post adds -nomac, which you didn't. Instead of turning off the MAC entirely, you could also try -macalg sha1.
--Something witty here questioning the use of a 10 year old OS (that only has 13 months of security updates remaining)--

For those who need it, i finally got it. Before execute the command from the other post, you have to export .key and .crt from your .p12 or .pfx certificate.

Related

Where do I get PEM encoded Private Keys and and DER encoded Certificate paths on Mac?

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.

deleting x.509 v3 extensions from issued certificate

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.

OpenSSL error generating a CSR from a private key

I have got a private key that I have exported from our .p12 file. The key has been used to successfully sign the application itself.
Now I need to generate a CSR from the key. This site advises using the following command for the task:
req -out CSR.csr -key privateKey.key -new
This yields the following error:
unable to load Private Key
6420:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:.\crypto\asn1\tasn_dec.c:1319:
6420:error:0D06C03A:asn1 encoding routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:.\crypto\asn1\tasn_dec.c:831:
6420:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:.\crypto\asn1\tasn_dec.c:751:Field=version, Type=RSA
6420:error:04093004:rsa routines:OLD_RSA_PRIV_DECODE:RSA lib:.\crypto\rsa\rsa_ameth.c:115:
6420:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:.\crypto\asn1\tasn_dec.c:1319:
6420:error:0D06C03A:asn1 encoding routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:.\crypto\asn1\tasn_dec.c:831:
6420:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:.\crypto\asn1\tasn_dec.c:751:Field=version, Type=PKCS8_PRIV_KEY_INFO
6420:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1 lib:.\crypto\pem\pem_pkey.c:132:
error in req
The error is the same as if I try
rsa -noout -text -in privateKey.key
The file does exist. What am I doing wrong and how can I fix it?
An alternative solution that did work.
1, Create a .pem file from the original .p12 (enter password when prompted)
openssl pkcs12 -in my.p12 -nocerts -out my.pem -nodes
2, Create the request from the .pem:
openssl req -new -key my.pem -out my.csr
You will be prompted to enter country, state, locality, organisation, unit and common names and your e-mail address, and extra attributes (challenge password and optional company name).
Done.
EDIT: also on CERN Certificate Authority's Prepare renewal certificate signing request(CSR) with OpenSSL.

Can SSL cert be used to digitally sign files?

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}

add or create 'Subject Alternative Name' field to self-signed certificate using makecert

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