SSL Cert Compilation into pem file - ssl

I recently purchased an SSL cert and need to setup HAProxy to use it.
The instructions from HAProxy are the following
The certificate specified in dockercloud/haproxy or in the linked application services is a pem file, containing a private key followed by a public certificate(private key must be put before the public certificate and any extra Authority certificates, order matters).
This article explains in more detail that the order should be the following...
—–BEGIN RSA PRIVATE KEY—–
(Your Private Key: your_domain_name.key) —
–END RSA PRIVATE KEY—–
—–BEGIN CERTIFICATE—–
(Your Primary SSL certificate:
your_domain_name.crt)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(Your Intermediate certificate: DigiCertCA.crt)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(Your Root
certificate: TrustedRoot.crt)
—–END CERTIFICATE—–
I received the following files after purchasing the SSL cert.
AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt
my_domain.crt
As well as I have a key file from CSR generation.
I ran the following
cat my_key_from_csr >> my_domain.pem
cat my_domain.crt >> my_domain.pem
cat COMODORSAAddTrustCA.crt >> my_domain.pem
cat AddTrustExternalCARoot.crt >> my_domain.pem
I copied the contents of my_domain.pem into HAProxy SSL_CERT variable, but it doesn't work. Am I doing something wrong?

You do not need to include the csr file as part of the pem. The following works 100% and I am using it w/ haproxy too.
cat your_domain_private_key.key >> your_domain.pem
cat your_domain_issued_certificate.crt >> your_domain.pem
cat COMODORSADomainValidationSecureServerCA.crt >> your_domain.pem
cat COMODORSAAddTrustCA.crt >> your_domain.pem
It is not necessary to add the Root CA (AddTrustExternalCARoot.crt) to the pem file as this is pre-installed already on all computers.

Related

use a lets encrypt certificate for another service

I have a Lets Encrypt certificate which works on my Synology NAS using a DDNS name. I want to use the certificate for another service (ejabberd) on another machine (a Raspberry Pi), that would run under the same DDNS name, but on another port.
I can download the certificate from the NAS resulting in three files:
cert.pem (CERTIFICATE)
chain.pem (CERTIFICATE)
privkey.pem (RSA PRIVATE KEY)
ejbberd's configuration needs the certificate file in two places:
### ===============
### LISTENING PORTS
listen:
port:5222
[...]
certfile: "/etc/ejabberd/certfile.pem"
and
s2s_use_starttls: optional
s2s_certfile: "/etc/ejabberd/certfile.pem"
s2s_protocol_options:
- "no_sslv3"
I am not sure which file to use here. I had this working, but the certificate expired.
It could be done by cat cert.pem chain.pem privkey.pem > certfile.pem
Here is a description and also (under appendix) a description of the certfile format. https://www.process-one.net/blog/securing-ejabberd-with-tls-encryption/

How to generate PEM files to install my own SSL certificate?

I have a SSL-certificate Comodo PositiveSSL.
There are files:
AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt
domain.com.key
domain_com.crt
Requirements vendor:
The certificate, private key, and certificate chain must be PEM-encoded
/ssl/test1.bx.key.pem
/ssl/test1.bx.cert.pem
/ssl/test1.bx.ca-chain.cert.pyem
Do I create PEM files correctly?
cat COMODORSAAddTrustCA.crt COMODORSADomainValidationSecureServerCA.crt AddTrustExternalCARoot.crt > domain.com.ca-chain.cert.pem
cat domain_com.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > domain.com.cert.pem
cat domain.com.key domain_com.crt COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > domain.com.key.pem
Do I create PEM files correctly?
No. The key file should not be the result of concatenated files. I don't know your vendor, but I believe domain.com.key = /ssl/test1.bx.key.pem
What I suppose to be expected from your vendor, but I can't be sure of course
/ssl/test1.bx.cert.pem = domain_com.crt
/ssl/test1.bx.ca-chain.cert.pyem = AddTrustExternalCARoot.crt + COMODORSAAddTrustCA.crt + COMODORSADomainValidationSecureServerCA.crt
To setup certificates in bitrix env you need to do next:
Concatenate the CAbundle and the certificate file which we sent you using next:
1.1. To concatenate the certificate files into single bundle file, first open domainname.crt and domainname.ca-bundle files using any text editor.
1.2 Now copy all the content of domainname.crt and paste it on the top of domainname.ca-bundle file.
1.3 Now save the file name as ‘ssl-bundle.crt’.
Store the bundle and private key in the appropriate nginx ssl folder /etc/nginx/ssl/example_com/
Add this lines to your nginx config:
ssl_certificate /etc/ssl/certs/ssl-bundle.crt;
ssl_certificate_key /etc/ssl/private/domainname.key;
ssl_prefer_server_ciphers on;
Restart nginx running command systemctl restart nginx.service.
Take a look into Comodo Knowledgebase about certificate installation on nginx. They described step-by-step how to install certificates on different web-servers.

creating valid test SSL certificates for IIS

I want to test SSL connections in an development environment with IIS. For this i need to crate a self-signed root certificate that gets installed in the machine store, and also another certificate that gets signed with the root certificate to install in IIS.
Doing it with makecert is deprecated now, so I am wondering how to do it with Powershell and the New-SelfSignedCertificate command.
Bonus points if you get the key usage settings right :-)
Note: using the self-signed certificated directly in IIS does not work, since the browser and WCF considers them invalid.
for reference, here is how to do it with makecert:
# create the self signed root certificate
makecert -n "CN=root.lan" -r -sv root.pvk root.cer
# create the certificate for IIS that gets signed with the root certificate
makecert -sk "Local Certificate" -iv root.pvk -n "CN=localhost" -ic root.cer -sr localmachine -ss my -sky exchange -pe
# convert to other formats
cert2spc localhost.cer localhost.spc
pvk2pfx -pvk localhost.pvk -spc localhost.spc -pfx localhost.pfx
The new version of New-SelfSignedCertificate, which included on Windows 10, is described here. One can use New-SelfSignedCertificate -? and get-help New-SelfSignedCertificate -examples to get some additional information.
The documentation and the examples could seems still not clear enough for creating two certificates:
one self-signed certificate, which will be used as CA certificate from your example
the second SSL certificate, which signed with the first certificate.
The implementation could be the following (I wrote below the option in multiple lines only to make the text more readable):
New-SelfSignedCertificate -HashAlgorithm sha384 -KeyAlgorithm RSA -KeyLength 4096
-Subject "CN=My Test (PowerShell) Root Authority,O=OK soft GmbH,C=DE"
-KeyUsage DigitalSignature,CertSign -NotAfter (get-date).AddYears(10)
-CertStoreLocation "Cert:\CurrentUser\My" -Type Custom
the output will look like
Directory: Microsoft.PowerShell.Security\Certificate::CurrentUser\My
Thumbprint Subject
---------- -------
B7DE93CB88E99B01D166A986F7BF2D82A0E541FF CN=My Test (PowerShell) Root Authority, O=OK soft GmbH, C=DE
The value B7DE93CB88E99B01D166A986F7BF2D82A0E541FF is important for usage the certificate for signing. If you forget the value you can find it by CN name
dir cert:\CurrentUser\My | where Subject -Like "CN=My Test (PowerShell)*"
or by usage certutil.exe -user -store My to display certificates on My store of the current user.
To create SSL certificate and to sign it with respect of previously created certificate one can do for example the following
New-SelfSignedCertificate -Type Custom -Subject "CN=ok01.no-ip.org"
-HashAlgorithm sha256 -KeyAlgorithm RSA -KeyLength 2048
-KeyUsage KeyEncipherment,DigitalSignature
-CertStoreLocation "cert:\LocalMachine\My"
-Signer cert:\CurrentUser\My\B7DE93CB88E99B01D166A986F7BF2D82A0E541FF
-TextExtension #("2.5.29.37={text}1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2","2.5.29.17={text}DNS=ok01.no-ip.org&DNS=ok01.fritz.box")
It seems to me that the final certificate will have all properties required. It's clear that the values from many from above parameters contains examples only any you have to modify there based on your requirements. I don't describe here some other common steps like importing root certificate in Trusted Root, exporting the certificates and so on. The steps are not the psrt of your main question.

Why is HAProxy unable to load certificates generated by letsencrypt?

HAProxy is unable to load .pem files generated by letsencrypt, why is this?
The error I'm seeing is:
parsing [/haproxy.cfg:37] : 'bind :443' : unable to load SSL private key from PEM file '/certs/cert0.pem'.
The contents of the PEM file is:
-----BEGIN CERTIFICATE-----
MIIFCjCCA/KgAwIBAgISATGh2D5ZMcKNqpIqViwd5EZOMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMTAeFw0xNTEyMTcwOTIyMDBaFw0x
NjAzMTYwOTIyMDBaMB4xHDAaBgNVBAMTE3N0YWdpbmcubXV6aGFjay5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrV1XqamfHm6tbDYAbnbjRxBw8
pxM/wPdO9RLUk5EmPnYy0XmPrbge93M5hh4qzMA7IGRxRa4xXjmj2nl4y6oLmRzF
nqHRBznh0D3u27dOmxk9vgWEGFO423T4W4DW5T6ukw+i2V5zxdtiu9tP7s8qsN7P
IxKQ8tPx8NB0PYXTg+DWhPQMZkX3Q63YEJrl6pR1kQ+shOg1WRw08/gfl8YCH0bj
AtbSPwwSNzNVylgA2IZX6mTrBYnbXJ5N63Ee/p1e+vw9fqxha4B4qPpNoByvgR27
cIGFjEoBzeS76awPzBnZLWNaVqM3E0YL9riQnAAgYPrqBIofV65GELBjwVRFAgMB
AAGjggIUMIICEDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFC5MVU7RKuD07ZwP6kGT
49qPO2tFMB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMHAGCCsGAQUF
BwEBBGQwYjAvBggrBgEFBQcwAYYjaHR0cDovL29jc3AuaW50LXgxLmxldHNlbmNy
eXB0Lm9yZy8wLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14MS5sZXRzZW5j
cnlwdC5vcmcvMB4GA1UdEQQXMBWCE3N0YWdpbmcubXV6aGFjay5jb20wgf4GA1Ud
IASB9jCB8zAIBgZngQwBAgEwgeYGCysGAQQBgt8TAQEBMIHWMCYGCCsGAQUFBwIB
FhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCBqwYIKwYBBQUHAgIwgZ4MgZtU
aGlzIENlcnRpZmljYXRlIG1heSBvbmx5IGJlIHJlbGllZCB1cG9uIGJ5IFJlbHlp
bmcgUGFydGllcyBhbmQgb25seSBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIENlcnRp
ZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL2xldHNlbmNyeXB0Lm9yZy9y
ZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAmcF6jtx6QWAOQtRLhnuDyViJ
9ISP2mw8Ueq5p3L/oBMebCAjS1qv7bCcHP5RyeaqsGrHclpv090JY44rCppj5oOh
OFzzsNqZ5dwLp8vNbPls1Y7ohThVxk5PfMGpfkDwpuZGxUkizB7qQtknjBr6lX2B
XX2/IknJnABU2ssh2q77aqeVkHYVWXYG8iNMETUcIys1/Mb7X/FdL1DGRhkS1kN0
geL/+e7pmusHijkSoOP7IXFgTfcnw1DiIPctXmH2/ETcQ5deWVTgOpCTBk0M1+d2
oFFNaePdQXk4iRYlJNrswoZCSgdqqUybvEcJDKvL+ogi6GwZpJCIn/Rc2PWhGQ==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEqDCCA5CgAwIBAgIRAJgT9HUT5XULQ+dDHpceRL0wDQYJKoZIhvcNAQELBQAw
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD
Ew5EU1QgUm9vdCBDQSBYMzAeFw0xNTEwMTkyMjMzMzZaFw0yMDEwMTkyMjMzMzZa
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAJzTDPBa5S5Ht3JdN4OzaGMw6tc1Jhkl4b2+NfFwki+3uEtB
BaupnjUIWOyxKsRohwuj43Xk5vOnYnG6eYFgH9eRmp/z0HhncchpDpWRz/7mmelg
PEjMfspNdxIknUcbWuu57B43ABycrHunBerOSuu9QeU2mLnL/W08lmjfIypCkAyG
dGfIf6WauFJhFBM/ZemCh8vb+g5W9oaJ84U/l4avsNwa72sNlRZ9xCugZbKZBDZ1
gGusSvMbkEl4L6KWTyogJSkExnTA0DHNjzE4lRa6qDO4Q/GxH8Mwf6J5MRM9LTb4
4/zyM2q5OTHFr8SNDR1kFjOq+oQpttQLwNh9w5MCAwEAAaOCAZIwggGOMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMH8GCCsGAQUFBwEBBHMwcTAy
BggrBgEFBQcwAYYmaHR0cDovL2lzcmcudHJ1c3RpZC5vY3NwLmlkZW50cnVzdC5j
b20wOwYIKwYBBQUHMAKGL2h0dHA6Ly9hcHBzLmlkZW50cnVzdC5jb20vcm9vdHMv
ZHN0cm9vdGNheDMucDdjMB8GA1UdIwQYMBaAFMSnsaR7LHH62+FLkHX/xBVghYkQ
MFQGA1UdIARNMEswCAYGZ4EMAQIBMD8GCysGAQQBgt8TAQEBMDAwLgYIKwYBBQUH
AgEWImh0dHA6Ly9jcHMucm9vdC14MS5sZXRzZW5jcnlwdC5vcmcwPAYDVR0fBDUw
MzAxoC+gLYYraHR0cDovL2NybC5pZGVudHJ1c3QuY29tL0RTVFJPT1RDQVgzQ1JM
LmNybDATBgNVHR4EDDAKoQgwBoIELm1pbDAdBgNVHQ4EFgQUqEpqYwR93brm0Tm3
pkVl7/Oo7KEwDQYJKoZIhvcNAQELBQADggEBANHIIkus7+MJiZZQsY14cCoBG1hd
v0J20/FyWo5ppnfjL78S2k4s2GLRJ7iD9ZDKErndvbNFGcsW+9kKK/TnY21hp4Dd
ITv8S9ZYQ7oaoqs7HwhEMY9sibED4aXw09xrJZTC9zK1uIfW6t5dHQjuOWv+HHoW
ZnupyxpsEUlEaFb+/SCI4KCSBdAsYxAcsHYI5xxEI4LutHp6s3OT2FuO90WfdsIk
6q78OMSdn875bNjdBYAqxUp2/LEIHfDBkLoQz0hFJmwAbYahqKaLn73PAAm1X2kj
f1w8DdnkabOLGeOVcj9LQ+s67vBykx4anTjURkbqZslUEUsn2k5xeua2zUk=
-----END CERTIFICATE-----
The problem is that I was using the fullchain.pem file generated by letsencrypt. Instead, one should concatenate it together with 'privkey.pem' (also generated by letsencrypt) into a single .pem file.
I could only fix this by using cert.pem instead of fullchain.pem when concatenating.
cat cert.pem key.pem > haproxy_cert.pem
Taken from https://www.haproxy.com/blog/haproxy-ssl-termination/:
frontend www.mysite.com
bind 10.0.0.3:80
bind 10.0.0.3:443 ssl crt /etc/ssl/certs/mysite.pem
default_backend web_servers
The ssl parameter enables SSL termination for this listener. The crt parameter identifies the location of the PEM-formatted SSL certificate.
This certificate should contain both the public certificate and private key.
To be honest, according with my experience on deploying HA Proxy with TLS/SSL end-to-end with minimum 2 nodes as Backend servers, this statement is somewhat true. In fact, HA Proxy requires fullchain.pem (instead of cert.pem) + privkey.pem as a single file. Not using fullchain.pem will lead to messages on Systemd like unable to load cert or things like that.
In a nutshell, you shall do:
$ cat fullchain.pem privkey.pem > /etc/haproxy/mydomain_certs/mydomain.pem
And not:
$ cat cert.pem privkey.pem > /etc/haproxy/mydomain_certs/mydomain.pem
This artile has a valuable example.
Just adding the issue that I encountered. The cat command generated concatenated the files without a newline between them. I manually inserted a new line (using vim) and it worked.
Also in my case I got three files from the registrar: crt, ca-bundle, and p7b. I just want to add that all I needed was the private key file and the crt file (so ca-bundle and p7b were not used).

How do I configure a Dropwizard application with intermediate certificate?

The Dropwizard example project has a single certificate without intermediate certificate and the HTTPS configuration doesn't mention anything regarding intermediate certs. Is it possible to configure Dropwizard to deliver intermediate certificates?
You should be able to add the intermediate certificate to the key store that you use for your certificate. To do that when you add the private key you should be able to add a chain of the signed public key with the intermediate certificate. The intermediate certificates should not be added by them selves The intermediate certificate should then also be sent to the client.
Dropwizard uses Jetty 9. From the Jetty 9 documentation:
If you have a chain of certificates, because your CA is an
intermediary, build the PKCS12 file as follows:
$ cat example.crt intermediate.crt [intermediate2.crt] ... rootCA.crt > cert-chain.txt
$ openssl pkcs12 -export -inkey example.key -in cert-chain.txt -out example.pkcs12
The order of certificates must be from server to rootCA, as per
RFC2246 section 7.4.2.
I would not include the root CA in the chain because it should be already known to the client.
OpenSSL will ask for an export password. Enter something and remember it for the configuration. The documentation includes further steps to convert the PKCS12 keystore to a JKS one, but that’s not required (PKCS12 works fine on Java 8u261).
Then configure the connector in your Dropwizard configuration file with the filename and password you used:
server:
applicationConnectors:
- type: h2c
port: 80
- type: h2
jceProvider: Conscrypt
port: 443
keyStorePath: example.pkcs12
keyStorePassword: foo
You can verify your configuration using OpenSSL:
openssl s_client -connect localhost:443
The section Certificate chain should show entries for your server certificate and the intermediate CAs.