I'm a newbie in computer security and I have a basic question whose answer I've not been able to find out.
I have a private key whose validity period has expired. Using that key I'd previously generated a .csr and sent it to a CA and they'd given me a certificate that's still valid.
My question is, can I (using keytool or whatever...) modify the private key's expiration date in order to use it with my certificate (.cer). Could I regenerate a private key to be used with this certificate?
Thank you,
No.
The validity period is in the certificate, not the private key. Certificates cannot be modified, and the only entities that can generate valid certificates are the certificate authorities.
You will have to pay for a new certificate. Certificate expiration is a safety measure, but also a way to get recurring customers.
keytool -genkeypair does more than generating a key pair: it generates a pair of public and private key, and wraps the public key into a self-signed X.509 certificate generated on the spot with the various options given (-dname, -validity, ...). It puts them together into the alias you choose (a private key entry will associate a private key and a certificate, or a certificate chain of length 1, to be precise).
Those options affect this self-signed X.509 certificate, not the key pair itself.
Normally, if you don't want to use a self-signed certificate, you produce a CSR based on this public key and the characteristics of this self-signed X.509 certificate (the structure of a CSR is in fact very similar to that of a self-signed certificate, but it doesn't have issuer or validity dates). That CSR is then used by your CA to issue an X.509 certificate (this time, signed by that CA).
You are meant to import it again into that alias, to be able to use the certificate with its private key. If your self-signed certificate (or an older certificate matching this private key) has expired, re-import the certificate that is still valid.
In fact, if there are intermediate certificates, you should not only import that certificate, but the certificate chain (see this question and this question).
If your .cer file is in DER format (binary) and not PEM format (base64-encoding of the DER format), you can convert it into PEM using openssl x509 -inform DER -in mycert.cer -outform PEM -out mycert.crt and use the result to build the chain and import it.
Related
I know this is probably a bad question but I am so confused. I have a tls certificate and a tls key file, tls.crt and tls.key. I think I'm supposed to convert them into a public and private key, relatively, in order to use openssl.
side note: Am I approaching this wrong? Is there some TLS application to encrypt/decrypt?
To convert the public key, I use
$ openssl x509 -pubkey tls.crt -noout > pubkey
This created a public key that I was able to encrypt a message file with by doing
$ opensssl rsautl -encrypt -inkey pubkey -pubin -in <message file> -out <encrypted output>
I have successfully encrypted the file but now I don't know how to decrypt it. I don't know how to convert my private key (tls.key) into an ssl private key. This is what stumps me. Shouldn't I be doing some tls encryption/decryption? If not, and I am supposed to be using openssl, how should I convert tls.key into a private key usable by openssl rsautl -decrypt?
tl;dr: The key file is the key file you want. No conversion should be required.
The trick here is in the following question: "What is a certificate?" The answer is that it is a signed public key that goes along with a secure private key. It (usually) gets signed by a CA ("Certificatation Authority").
The basic process is:
Entity that wants a certificate creates a private/public key pair.
Entity send the public key and some information about the Entity to the CA.
The CA performs "some level" of validation on the Entity, verifying their identity. Usually this is just some level of proof that the requestor owns the web site the certificate is to be used for.
The CA takes the provided public key and the other info provided, uses their private key to generate a signature for that data, which then can be verified by decrypting the signature using the CA's public key. That becomes your certificate.
So, you took your own public key from the certificate. The private key (tls.key) should be the key file you created in the first step - just use it on your encrypted data.
How to introduce one level of certificate chain while signing a jar file? What I am trying to do is,
Sign a jar with generated private key.
Generate a CSR (Certificate Signing Request)
Generate a CA signed certificate where CA is self sign CA
import CA in jcontrol and browser and run the java web start application.
but unfortunately it didn't work and gave security warning.
Please suggest some good approach.
TLDR: get the cert first
Java codesigning uses the PKCS7/CMS signature format, wbich is based on X.509/PKIX public-key certificates. The sequence you posted uses the privatekey as it if magically appeared, but that is impossible. I'm going to bet your sequence actually was:
0. keytool -genkeypair
Although the name focusses attention on 'generate keypair', this single command actually does three things: generate a keypair; create a dummy, self-signed certificate for the public half of that keypair; and store both the private half of the keypair and the dummy certificate together in a keystore (usually a file). Note the java.security.KeyStore API does not support storing a privatekey -- or a publickey or raw keypair -- by itself, only a privatekey combined with a certificate chain. (The dummy cert, by itself, constitutes a trivial chain.) For concreteness I will call this dummy cert A.
1. Sign a jar with generated private key = jarsigner
You specify to jarsigner a privatekey entry in a keystore, but as above that entry actually contains the cert chain as well, in this case the dummy cert. The PKCS7/CMS signature contains a raw PKC signature (RSA, DSA, or ECDSA) computed using the privatekey, plus the cert which matches that privatekey and thus can be used to verify the signature, plus any chain cert(s) needed to validate the signing certificate. You can see this if you look at the contents of the META-INF/<alias>.{RSA,DSA,EC} entry in the resulting jar.
2. Generate a CSR (Certificate Signing Request) = keytool -certreq
3. Generate a CA signed certificate where CA is self sign CA
How you did this depends on your CA, but doesn't matter here. To be exact, a CA may have a self-signed cert for the public half of the CA keypair, but as above it actually signs certs it issues using the private half. For concreteness I will call the cert issued by the CA for the signing key B, and the CA's own self-signed cert C.
4. import CA in jcontrol and browser and run the java web start application.
I'm not sure if you mean B or C here. But neither will help in verifying the signature done in step 1, because that signature contains and specifies A as the 'signer' cert, i.e. the cert to be used to verify the signature. B is a cert fort for the same publickey, and could be used to verify the signature if the signature specified cert B, but it doesn't, and can't because B didn't even exist when the signature was created.
The correct sequence is:
-genkeypair
-certreq
use CSR to get cert B from CA. You don't actually need C here, although you might get it for convenicnce or reference.
-importcert cert B into the privatekey entry. (If you defaulted the -genkeypair alias to mykey you can default -importcert also, otherwise you must specify the same one.) This replaces the dummy cert A with the 'real' cert B in the privatekey entry. (Be careful not to import cert B to a different alias, or different keystore; this often doesn't give an error. but the result won't work correctly.)
If the 'real' cert B needs one or more chain cert(s) to validate, as is (always?) true for certs from real public CAs like Digicert, GoDaddy, LetsEncrypt, etc, such chain cert(s) must be either included in step 4 (as a combined file, often a 'p7b' or 'p7c' file), or separately imported prior to step 4 into a separate trustedcert entry or entries. However, your in-house CA does not need any chain cert(s).
now jarsigner -- so the signature includes cert B (and its chain certs if any)
A. separately, cert C must be included in the truststore(s) used by the client system(s); this can be done anytime: after, during or before steps 1-5. For webstart, I believe putting it in Java Control Panel should be sufficient; AFAIK webstart isn't validated by the browser. Applets may have been, but applets haven't worked in browsers for several years or in Oracle Java higher than 8.
I'm new to setting up ssl for curl. We were given a .cer file and the admin created a private.key. When we tried to associate the .cer with the private.key, the modulus's don't match. Is there a way to correct this? it would be easier to recreate the private.key with the proper modulus but I'm unsure how to do this without wrecking the openssl configuration.
any assistance would be appreciated!
Tom
Something wrong with the process here. You can't be just 'given' a certificate and then create a private key for it. The process goes like this:
You create a private key.
You create a certificate signing request (CSR).
You submit the CSR to some certificate authority (CA).
They verify your identity and then issue you a signed certificate.
The CSR and the signed certificate both contain the public key corresponding to the private key you first created.
Amazon Cloudfront is giving me errors, either my private key doesn't match my public key certificate or my public key certificate cannot be parsed as it's invalid.
Using Godaddy for my SSL certificate middle man/provider, I got a:
.pem whoose contents beings with "-----BEGIN RSA PRIVATE KEY-----"
(I'm assuming that's my private key)
Inside Godaddy I am able to download some certs for the SSL, they are:
.crt (type = Security Certificate)
.p7b (type = PKCS #7 Certificate)
Is one of the above my public key? Or is there another way I am supposed to get my public key?
I have encountered this issue before with bad CSR Request.
According to GoDaddy:
To install a digital certificate, you must first generate and submit a Certificate Signing Request (CSR) to the Certification Authority (CA). The CSR contains your certificate-application information, including your public key. Use your Web server software to generate the CSR, which will also create your public/private key pair used for encrypting and decrypting secure transactions.
http://support.godaddy.com/help/article/5343/generating-a-certificate-signing-request
It also states: NOTE: When generating your CSR, specify a key size of 2048 or higher.
The key size is sometimes the culprit. Hope it helps.
I'm confused about something in the SSL renewal process using WHM/cPanel for an existing Comodo Extended Validation cert.
We have been issued a replacement certificate by Comodo without - I believe - every submitting a CSR for them. I say "I believe" because there are 3 people with access to WHM for this server, but I'm assured that no one has been fiddling in the last year.
Does this sound possible? CAN a cert be supplied without a CSR if it's a replacement? I will attempt to get hold of Comodo but being a weekend, and seeing that the old cert runs out in a day I thought I'd consult the stackHiveMind :)
More info:
As a test, I've tried to install the new cert and 'fetch' the existing private key, but when I try to submit that I get the following error:
SSL install aborted due to error: Modulus mismatch, key file does not match certificate. Please use the correct key file
In some cases, yes, you can. Assuming you have an RSA private key in PEM format, this will extract the public key (it won't generate a certificate):
openssl rsa -in key.pem -pubout -out pubkey.pem
This will create a new CSR with the public key, obtained from the private key file.
openssl req -new -key key.pem -out host.csr
Note that, strictly speaking, a CA doesn't need you to submit a CSR to issue a certificate. All it needs is the public key (to which it will have access through your existing cert). It could potentially attach any Subject DN and attribute and issue it as a certificate without any need to contact you. Of course such practices might be incompatible with their policies, but technically, it's possible. The CSR is merely a convenient format for you to send a public key to request a certificate, and submit the name and attributes you would like (which you all sign together).
SSL install aborted due to error: Modulus mismatch, key file does not
match certificate. Please use the correct key file
Provided you've done the certificate operations properly, this could indicate that the new certificate you've been issued has been issued against a different key-pair than yours. This could indicate foul play, because someone else could have issued a CSR with their own key-pair and have had this certificate issued to them (which could be quite worrying since you're talking of an EV cert too, which is supposed to have additional protections against this.)
I would suggest checking with your colleagues if any have requested a new certificate or contacting your CA to find out why you've received a new certificate. Renewing the certificate using the previous public key might be part of their existing package. If it's using the same public key, it's not a problem, although it's better practice to change the key material, i.e. submit a CSR coming from a new key-pair, when renewing a certificate.