Correct. The relevant standard is the X.509 spec in RFC5280:
The certificate validity period is the time interval during which the
CA warrants that it will maintain information about the status of the
Basically, as the certificate requester, you have absolutely no say in the validity period of your cert, ...
If you do it properly, nothing.
The usual process for getting a TLS (formerly SSL) certificate from a CA is:
Generate server.privkey and server.csr (or equivalent) files on your machine. Keep the private key private.
Send the server.csr (certificate signing request) to the CA to get signed and become a certificate.
Take the certificate the CA gives you ...
To sign the CSR:
openssl x509 -req -days 365 -in private.csr -signkey ca.key -out test.crt
From man x509:
-signkey filename ... If the
input is a certificate request then a self signed certificate is
created using the supplied private key using the subject name in the
In other words: you are creating a self signed certificate with ca.key ...
As per this answer CSR with only public key with openssl
The CSR only contains your public key, not your private key, so your private key has not been compromised.
The .csr files will both still be valid no matter what.
When you send the CSR to a Certificate Authority, they will produce a signed x509 Certificate. Any computer that trusts the CA will then ...
A CSR allows a user to get a certificate authority (CA) to give them a signed certificate, without the CA actually knowing the user's private key. An X.509 cert has a few major pieces: the subject (who the cert is for), the cert's validity period, the cert's allowed uses, the subject's public key, and the issuer's signature (that is, a signature generated ...
Generating CSR is not platform specific, it's true as you say, that you only need the primary key and private key isn't tied to a specific machine.
However, especially in a beginner's tutorial, there are a couple of reasons why this advice can be sensible:
It limits the private key to just the machine that will use it. You won't have copies of the key ...
As indicates by @StackzOfZtuff, the problem is you aren't telling openSSL to include SAN in your CSR.
A guide on doing so can be found here, and basically suggests doing:
[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
req_extensions = req_ext # The extentions to add to the self signed ...
Re. 2: Dunno. But it seems wrong to give a named curve explicitly and let the other end figure out Hey! That's actually one of the named curves I support!
The OpenSSL Wiki has this to say: (line breaks mine)
Parameters and key files can be generated to include the full explicit parameters instead of just the name of the ...
Yes, you can. You just need to have the private key in the proper format to be used by openssl.
Not knowing in which format you exported, it's impossible to provide commands, but -supposing it can't sign directly with it- openssl x509 may be able to convert the file.
PKCS#10 is a specification defining what and how attributes should be contained in a Certificate Signing Request in order for it to be compliant. It is used as the default specification for most certificate signing authorities. This specification dictates the use of ASN.1.
ASN.1, also known as Abstract Syntax Notation One, is a standard that defines rules ...
A private key isn't just a big number, it is actually a data structure with several numbers in it.
Here's what a public key looks like (RSA):
A certificate signing request is the precursor of a CA signed certificate. Thus a CSR is needed wherever CA issued certificates are used: server authentication, client authentication, creation of a sub-CA, signing mails with S/MIME, signed applications ...
The signature created by the issuer of the certificate is fully independent of the algorithm used in the certificates public key. The signature algorithm instead depends on the issuers key and not the certificates key. It is actually common to have certificates containing an ECC key signed with RSA.
This is correct. openssl x509 is only a tool to manipulate and create certificates, but it is not a standalone CA and does not keep any status. Whereas openssl ca is described in the documentation as:
The ca command is a minimal CA application. It can be used to sign certificate requests in a variety of forms and generate CRLs it also maintains a text ...
Many cryptographic APIs support network-attached Hardware Security Modules (HSMs), and using those APIs would already seem to qualify for your theoretical construct.
.NET Core has a CertificateRequest class. If you make a custom class which extends RSA to communicate with KeyVault (or use an existing one) then you can create certificates where the signing ...
Self-signed certificate means that the certificate is signed by itself. Since signing is done with the private key you need the private key which matches the public key in the certificate. This means that if you want to keep the public key from the CSR you also need the matching private key.
Is the contents of the CSR hashed and signed by the server's private key?
Is the CSR encrypted?
Is the CSR transported in clear text to CA to re-hash and verify the contents?
How does CA verifies the hash of the signed CSR?
The CSR is signed with the server's private key. To verify the signature the server's public key is needed. This ...
If you compare the output from openssl req -in yourcsr.pem -text with CSR created by the usual openssl commands you will find, that the version is shown as 1 in your CSR while 0 in the usual CSR:
Version: 1 (0x1)
This is due to the following code:
int nVersion = 1;
ret = X509_REQ_set_version(x509_req, ...
It is typically the responsibility of the CA to only sign extensions they approve (typically described in their CPS), and may add extensions according to the type of certificate. I would check with the CA.
For most CAs they will discard the extensions you supply and only add the ones they include from their own template/certificate type. As an example, you ...
Each tool should be used for what it does the best. The HSM is great to protect a private key by allowing to use it without leaking it out the the hardware module.
But IMHO, the CSR generation and validation should be done before submitting a validated CSR to the HSM for signature only.
Do not even try to authenticate applications, just authenticate users! And if you want serious PKI management procedures, a private key should always be under exclusive control of its owner: it is a key requirement for non repudiation. If A builds the CSR and after B signing them gives them to C and D, an admin from A company could keep a copy of the private ...
Company A as a software provider will need to make sure either:
With embedded certificate:
A sends a separate CSR to B with a different key for each customer C
A embeds the respective private key into the executable before
delivery to either C or D. This exposes the private key during delivery.
With no supplied certificate (alternative solution)...
if C finds out D's X-USERNAME then they can access D's data which seems even less secure than userID/password.
Can they? B might generate a separate certificate for each customer which can only be used to access their data. The X-Username header might simply be metadata. But you might want to try this out to be sure. Especially when they don't ask for which ...
Key exchange and certificate verification are independent operation.
"an a ECDHE_ECDSA_* certificate be signed by a CA with RSA and still be within spec."
First part i.e ECDHE is for key exchange
ECDSA is for digital signature verification of server certificate
so ECDHE certificate is actually signed by RSA or DSA by CA.
if both key exchange and certificate ...
A CSR is just a signing request, as long as you have the private key used for the CSR, the signed certificate you get via that CSR and they key can be used anywhere on any machine.
By telling users to do all of those things on the same machine, they are less prone to use the wrong combination of keys and certs, which means less support calls for the CA.
No, they are not the same. A public key is actually one member of a "key pair", consisting of both a public key and the matching private key. The CSR is a Certificate Signing Request, which is just a form you fill out.
When creating a CSR, you attach your public key to it and fill in other needed data; you then send it to a Certificate Authority (CA). ...
Upon certificate retrieval, client executes certificate chaining engine (at least, Microsoft CryptoAPI does) and validates the certificate. This includes full certification path, trust and signature validation. Since, the certificate is signed by CA, certificate tampering will be detected immediately.
Your question is scattershot and not very clear so this can't be a complete answer
the firstname of the self sign has to be my domain name?
Only for SSL/TLS server -- mostly.
What Java keytool prompts as first and last name is the CommonName attribute in the Subject name (also Issuer name for selfsigned). For SSL/TLS servers it used to be required that ...
You seem to have some misunderstandings.
If you make a certificate with a CA, they do not give you a private key. You have the PK of your certificate already, and the PK of the CA is secret.
With an self-signed certificate, you're acting as certificate holder and CA at the same time. Naturally, telling the people "I say that I'm thrustworthy" doesn't ...