If you obtained the wildcard certificate using certbot you should have 4 files:
Domain cert
Intermediate cert
Concatenation of cert.pem and chain.pem
Private Key
/etc/letsencrypt/live/domain/cert.pemIntermediate cert
/etc/letsencrypt/live/domain/chain.pemConcatenation of cert.pem and chain.pem
/etc/letsencrypt/live/domain/fullchain.pemPrivate Key
/etc/letsencrypt/live/domain/privkey.pem
If you obtained the wildcard cert using a web service or another client you should let us know which one.
In case you already have the 4 files in
/etc/letsencrypt/live/domain/ and as you are using Apache 2.4.6 you should modify your Apache conf:
Now:
<VirtualHost *:443>
SSLEngine on
ServerName service1.domain
DocumentRoot /srv/www/service1.domain/
SSLCertificateFile /etc/letsencrypt/live/domain/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/domain/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
# SSLCertificateChainFile /etc/letsencrypt/live/service2.domain/chain.pem
</VirtualHost>
What Is An Intermediate Certificate?
Posted by Leonard Grove on 20 August 2011 08:29 PM
| |
| To enhance the security of the Root certificate, we create two intermediate certificates from which SSL certificates are signed and issued. An intermediate certificate is a subordinate certificate issued by the trusted root specifically to issue end-entity server certificates. The result is a certificate chain that begins at the trusted root CA, through the intermediate and ending with the SSL certificate issued to you. Such certificates are called chained root certificates. Creating certificates directly from the CA root certificate increases the risk of root certificate compromise, and if the CA root certificate is compromised, the entire trust infrastructure built by the SSL provider will fail. The usage of intermediate certificates for issuing SSL certificates to end entities, therefore, provides an added level of security. You must install the intermediate certificate in your Web server along with your issued SSL certificate to complete the trust chain and allow the certificate to be effective. Using intermediate certificates does not cause installation, performance, or compatibility issues. | |
https://support.ssl.com/Knowledgebase/Article/View/11/8/what-is-an-intermediate-certificate
How SSL Works:
https://www.youtube.com/watch?v=33VYnE7Bzpk&t=290s
Certificate:
A certificate contains a public key.
The certificate, in addition to containing the public key, contains additional information such as issuer, what the certificate is supposed to be used for, and other types of metadata.
Typically, a certificate is itself signed by a certificate authority (CA) using CA's private key. This verifies the authenticity of the certificate.
Differences between .pem and .cert
our keys may already be in PEM format, but just named with .crt or .key.
If the file's content begins with
-----BEGIN and you can read it in a text editor:
The file uses base64, which is readable in ASCII, not binary format. The certificate is already in PEM format. Just change the extension to .pem.
If the file is in binary:
For the server.crt, you would use
openssl x509 -inform DER -outform PEM -in server.crt -out server.crt.pem
For server.key, use
openssl rsa in place of openssl x509.
The server.key is likely your private key, and the .crt file is the returned, signed, x509 certificate.
If this is for a Web server and you cannot specify loading a separate private and public key:
You may need to concatenate the two files. For this use:
cat server.crt server.key > server.includesprivatekey.pem
I would recommend naming files with "includesprivatekey" to help you manage the permissions you keep with this file.
If not conversion needed:
openssl rsa -in server.key -text > private.pem
openssl x509 -inform PEM -in server.crt > public.pem
In summary, there are four different ways to present certificates and their components:
- PEM - Governed by RFCs, its used preferentially by open-source software. It can have a variety of extensions (.pem, .key, .cer, .cert, more)
- PKCS7 - An open standard used by Java and supported by Windows. Does not contain private key material.
- PKCS12 - A Microsoft private standard that was later defined in an RFC that provides enhanced security versus the plain-text PEM format. This can contain private key material. Its used preferentially by Windows systems, and can be freely converted to PEM format through use of openssl.
- DER - The parent format of PEM. It's useful to think of it as a binary version of the base64-encoded PEM file. Not routinely used very much outside of Windows.
No comments:
Post a Comment