I'm trying to convert my .crl file into a .pem on my Red Hat server with openssl but it fails with:
openssl crl -in lab-rootca-ca.crl -inform DER -out lab-rootca-ca.crl.pem
unable to load CRL
139996682680136:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1343:
139996682680136:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:393:Type=X509_CRL
I see that the format is x509 but the inform flag doesn't support it. What am I missing?
I have on Windows server certificate which is valid and active and WinRM listener is active as well on port 5986 (telnet works) for WinRM connection that needs to be established from the Linux server.
I didn't copy that certificate anywhere on the linux server as I do not know where that should be or how it should be configured.
If I try to establish WinRM connection I am getting this error on the Linux server.
openssl s_client -connect 10.7.147.210:5986
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 1367 bytes and written 447 bytes
Verification error: unable to verify the first certificate
I tried by referencing CAfile and CApath and cert option but without success:
openssl s_client -cert winrmcert.pem -key winrmcert.key -CApath . -connect 10.7.147.210:5986
openssl s_client -CAfile winrmcert.pem -connect 10.7.147.210:5986
Can you please help me what I need to do and configure on Linux server for certificate generated on Windows server for WinRM connection? I am not the expert for this topic so I would appreciate all useful instructions. Thank you
Environment - Multihost Env(4org,1 org hosting entire raft clusters)
Followed the fabric-ca operations guide till genesis block everything went fine but while creating the docker for ordering service found the following error:
[orderer.common.server] initializeServerConfig -> INFO 004 Starting orderer with TLS enabled
orderer1-org0 | panic: runtime error: index out of range 1 with length 1
The below commands when executed confirm the hash for key,ca are same but doesn't match with tls-ca
openssl pkey -in hyperledger/org2/peer1/tls-msp/keystore/key.pem -pubout -outform pem | sha256sum
openssl x509 -in hyperledger/org2/peer1/tls-msp/signcerts/cert.pem -pubkey -noout -outform pem | sha256sum
openssl x509 -in hyperledger/org2/peer1/tls-msp/tlscacerts/tls-orderer1-org0-7052.pem -pubkey -noout -outform pem | sha256sum
Can you help to identify in which particular step in operation guide would have caused the error so that I can rerun from that if I need to restart completely then what is the change or caution that I need to consider. Note the passwords for the ca and tls-ca for certain identities are different as per the latest operation guide hope this didn't cause the issue. Attached the docker for the orderer and screenshot of the file.
[![enter image description here][2]][2]
https_options:
{ key: '/etc/letsencrypt/live/mywebsite.com/privkey.pem',
cert: '/etc/letsencrypt/live/mywebsite.com/fullchain.pem' }
I just do https.createServer with the above options and get this error:
_tls_common.js:134
c.context.setCert(cert);
^
Error: error:0909006C:PEM routines:get_name:no start line
at Object.createSecureContext (_tls_common.js:134:17)
at Server.setSecureContext (_tls_wrap.js:1017:27)
at Server (_tls_wrap.js:897:8)
at new Server (https.js:61:14)
at Object.createServer (https.js:84:10)
at startWWW (myserver.js:192:9)
I tested the key/cert pair like this: (as others suggested in other questions, blog posts, forum threads)
openssl x509 -text -in /etc/letsencrypt/live/mywebsite.com/fullchain.pem
openssl rsa -text -in /etc/letsencrypt/live/mywebsite.com/privkey.pem
Both commands printed multiple lines of seemingly valid output.
lsb_release -a | grep Description
Description: Ubuntu 18.04.2 LTS
This should fix it:
key: fs.readFileSync('/etc/letsencrypt/live/mywebsite.com/privkey.pem', 'utf8'),
do the same for the cert too .(eg read in utf8 encoding)
I used IIS 7 on Windows Server Enterprise 2008 to generate a self-signed cert for use with IIS (basically one-click button).
However, even when I export and add this cert to a windows client's curl-ca-bundle.crt, neither it nor openssl.exe will not verify the cert correctly:
openssl s_client -CAfile curl-ca-bundle.crt -showcerts -connect myserver.ad.pri:443
CONNECTED(00000003)
depth=0 /CN=myserver.ad.pri
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=myserver.ad.pri
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=myserver.ad.pri
i:/CN=myserver.ad.pri
-----BEGIN CERTIFICATE-----
MIIDADCCAeigAwIBAgIQTi9gdBLdo6pJ1h4Zljr/wzANBgkqhkiG9w0BAQUFADAp
....
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=myserver.ad.pri
issuer=/CN=myserver.ad.pri
---
No client certificate CA names sent
---
SSL handshake has read 924 bytes and written 444 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Start Time: 1377728216
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
read:errno=104
I used IE to export the cert to Base-64 Encoded, which is openssl-readable as PEM:
openssl x509 -inform PEM -in myserver.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
4e:2f:60:74:12:dd:a3:aa:49:d6:1e:19:96:3a:ff:c3
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=myserver.ad.pri
Validity
Not Before: Aug 26 15:38:46 2013 GMT
Not After : Aug 26 00:00:00 2014 GMT
Subject: CN=myserver.ad.pri
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
....
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage:
Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
Signature Algorithm: sha1WithRSAEncryption
...
-----BEGIN CERTIFICATE-----
....
openssl/curl with the same curl-ca-bundle.crt will verify certs from google.com:443 etc. just fine.
I also ran into this (and I'm very surprised more people haven't.) when I couldn't get a NodeJS HTTP(s) client to connect to an IIS instance with a self-signed-certificate on it (one created through IIS manager) Just got the dreaded' unable to verify the first certificate error!
It seems that this is because the certificates that IISManager creates for this purpose specify some 'Key Usage' extensions; 'Key Encipherment' and 'Data Encipherment'.
It turns out that when openssl encounters a certificate that specifies 'Key Usage' but fails to specify the 'certSign' usage then the openssl code will discount that certificate as a possible CA certificate even if it has been correctly provided to the openssl code (meaning it is unable to verify the certificate against said absent CA!).
(See the logic here https://github.com/openssl/openssl/blob/6f0ac0e2f27d9240516edb9a23b7863e7ad02898/crypto/x509v3/v3_purp.c#L503 )
The solution is as the one already above, which is to create your own certificates with the correct key usages (or no key usage extensions!)
I also thought I should include an alternative way of creating the Self Signed certificate that openssl clients would be happy with if you're in windows land.
First download the powershell script from here
In a powershell console (Administrative) execute the following commands from within a folder that contains the downloaded scripts
New-SelfsignedCertificateEx -StoreLocation "LocalMachine" -KeyUsage "DigitalSignature,KeyEncipherment,KeyCertSign" -Subject "CN=<HOST_NAME_TO_USE>" -FriendlyName "<HOST_NAME_TO_USE>" -SignatureAlgorithm sha256 -SubjectAlternativeName "<HOST_NAME_TO_USE>","anotherhost.org","someotherdomain.com"
Once you've executed the above command your LocalMachine\Personal Certificates store will contain a self-signed certificate that can be used by IIS for its SSL communications. (Please note you may also need to copy this certificate into one of the Trusted Root stores as well to guarantee that the certificate is trusted on that machine)
I solved this by using openssl to create a self-signed CA cert, then created a server cert request (also in OpenSSL, for some reason openssl does not like to sign requests generated by IIS), signed it with the former CA cert, then exported to PKCS12. Then imported into IIS. Once the CA cert is added to curl-ca-bundle.crt, it will verify the chain correctly:
Generate a CA:
openssl req -new -x509 -days 3650 -extensions v3_ca \
-keyout cakey.pem -out cacert.pem -config /etc/ssl/openssl.cnf \
-newkey rsa:2048
Generate a server key and signing request:
openssl req -new -nodes -out server-csr.pem -keyout server-key.pem -newkey rsa:2048
Sign the request with the CA:
openssl ca -config /etc/ssl/openssl.cnf -cert cacert.pem -keyfile cakey.pem \
-out server-cert.pem -in server-csr.pem
Export the server cert to PKCS#12:
openssl pkcs12 -export -out server-key-cert.pfx \
-inkey server-key.pem -in server-cert.pem -certfile cacert.pem
Import server-key-cert.pfx into IIS. (Re)bind the site binding's SSL binding to the cert.
Append cacert.pem to clients' curl-ca-bundle.crt. openssl s_client -showcerts -CAfile curl-ca-bundle.crt -connect server:443 has depth 0 and 1 and will verify return.
Notes: Make sure that keyUsage = nonRepudiation, digitalSignature, keyEncipherment is enabled under section [usr_cert] in openssl.cnf else requests won't contain those keyUsage and IIS will complain on binding.