How to send ssl certificates?

Question

Digital certificates

Hello everyone)

I have a couple of questions about ssl certificates, can anyone help me figure it out?

From the previous developer, I got the code where there is a connection to one service. That service is accessed by a curl request sending an ssl certificate. The certificate has expired. I looked at the instructions for connecting to the service. It says that you need to generate a new certificate using OpenSSL and send it to them for signing.

Here is the command openssl req -new -newkey rsa:2048 -nodes -keyout cert.key -sha1 -out cert.csr

But before I had time to send them anything, they sent me a new certificate.

1) How did they generate it without a request? Like an old request? That is, the request has no expiration date?

2) The certificate that they sent me, if you look through a special program, on a macbook it's keychain access, you can see that our develop environment domain is specified as the domain. But requests for this certificate are sent from any other domain. What for then in the certificate in general to specify the domain if it is possible to send requests from any? Or do they somehow set it up when they sign the certificate on their side? I just thought that if the certificate was created for a specific domain (common name is specified), then requests for this certificate will only work from that domain.

3) Among the certificates on this project were two keys. One with

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

Second

-----BEGIN RSA PRIVATE KEY-----
----END RSA PRIVATE KEY-----

I verified that both of these keys belong to the certificate using the commands to calculate the certificate module hash:

openssl x509 -noout -modulus -in <filename>.crt | openssl md5
openssl rsa -noout -modulus -in <filename>.key | openssl md5

It turned out that although these keys look different, they both fit the certificate. Esteemed about a difference of these keys. It turned out that this is one key, but in different formats, the first in the new PKCS8 format, and the second in the old PKCS1 format. The only difference is that in the new format its type is encrypted in the key, if I understand correctly.

3.1 I tried to send requests with both keys, but it came out only with a key in the new PKCS8 format, why are they the same?

3.2 Sending a request is only possible if the key is specified in the certificate file itself, that is, I combined them into one file and then the request worked. Why doesn't it work individually?

3.3 Do I understand correctly that the PKCS1 and PKCS8 key formats have nothing to do with the pem format? That is, a pem file can be in PKCS8 format, like some kind of subformat? Or are all of these generally different formats, and if the file is in PKCS8 format, does this mean that it is not in pem format?

3.4 Are the PKCS1 and PKCS8 formats just for keys or for a certificate too?

3.5 If these are the formats for the certificate, then it may be that the old key, although it belongs to the certificate, but requests are not sent with it because it is in the PKCS1 format, and the certificate itself is valid in the PKCS8 format? That is, the certificate and key must be in the same format?

3.6 Is it possible to somehow define key and certificate formats? I understand that the file extension does not mean anything at all? That is, there can be a certificate with the .pem extension, but the key format can be PKCS8?

I would be grateful if someone could answer at least some of these questions.

Answer 1

That is, the request has no expiration date?

No. CSR is just a collection of information

But requests for this certificate are sent from any other domain. What for then in the certificate in general to specify the domain if it is possible to send requests from any?

Why is the registration address in the passport if they don’t look at it when buying booze? Then, what can be seen in another case. Validation against a client certificate in the simplest case can take place simply by the very fact of issuing a certificate by a certain CA. In this case, it does not matter at all what CN is entered there. Also, validation can take place both by CN and by additional fields of the certificate.

Sending a request is only possible if the key is specified in the certificate file itself, that is, I combined them into one file and then the request worked. Why doesn't it work individually?

Read the mana carefully, see the parameters for specifying the certificate key. True, it is possible that they do not exist, then merging the key and certificate is the only possible way. However, the key cannot be encrypted with a password.

Do I understand correctly that the PKCS1 and PKCS8 key format have nothing to do with the pem format?

PEM is a type of information storage . Implicitly implies BASE64 storage format. There is also the DER format - storage in binary form. PEM can be sent by mail, inserted into documents - it's text. DER is not possible.

Answer 2

The universal rule is not to use in production any certificates whose private key was not generated by you and which was sent somewhere. If you need to update / re-release - generate the key yourself, send the CSR from it where necessary, and then let them do what they want.
In general, if we are talking about public domain names (under your control), then all dances with certification centers are solved by setting Let`s Encrypt once.

Answer 3

3.4 Are the PKCS1 and PKCS8 formats just for keys or for a certificate too?

https://en.wikipedia.org/wiki/PKCS

3.2 Sending a request is only possible if the key is specified in the certificate file itself, that is, I combined them into one file and then the request worked. Why doesn't it work individually?

Well, because TSL is not done by keys, but by certificates with keys. For example, the key pair does not contain information about expiration dates and there is no chain of trusted certificates to verify validation.

But before I had time to send them anything, they sent me a new certificate. How did they generate it without a request? Like an old request? That is, the request has no expiration date?

The generation of certificates for communication between two services is negotiated between the developers of these services. If you are using self-signed certificates, then anyone can generate. If you use the same CA that is available to both teams, either team can request a new certificate. If you work in different companies, each has its own internal CA and procedure for obtaining certificates, then they could not generate a new certificate, but if they could, then this is not the case.

But requests for this certificate are sent from any other domain. What for then in the certificate in general to specify the domain if it is possible to send requests from any?

Usually the certificate is on the server that matches the domain, not on the client.
When you go to google.com via HTTPS, you can do it from any computer, and not just from the Google server?
You just need to figure out why you use certificates - for TLS, for two-way TLS, or for authorization.
You need to figure out how validation is checked for you - maybe you just have ignoreinvalidcert and that's all
No one except you will figure it out in your application. Bring up someone who made the architectural decision and figure out how you should do it, and do it. And it is quite possible that even as you planned it does not work for you now.

Answer 4

1) To generate a certificate, it is not necessary to make a request, especially since you have a certificate for client authorization. The difference is in the private key, if you send a request, then only you will have the private key, if they sent you a certificate, then this is a new pair of certificate + key. Accordingly - not only you have the key)
2) This is a client certificate. It checks other fields, it is not tied to a domain. Required to identify the client on the server (analogue login + password, but cooler in terms of security)
3) Yes, these are just different recording formats. Different applications require different formats.
3.1) Different applications require different formats.
3.2) Different applications require different formats.
3.3) pem - determines that this file stores a certificate. Implies, but does not define, the format of the certificate entry in it.
3.4) Public-Key Cryptography Standards - the answer is in the title.
3.5) The old key will not work for you, because. they generated a new key and signed a new certificate with them and sent it to you.
3.6) Yes, the file extension may not match the content.
It is possible by enumeration

openssl pkcs12 -text -in certificate.pfx
openssl x509 -text -in certificate.pem
openssl pkcs8 -text -in certificate.cer