What error currently exists in the ssl.cnf file or code that is leading to the following output in zsh? - ssl

Recently I was working on a project that utilized the Alexa AVS Sample App (the one written in java, and currently in maintenance mode: https://github.com/alexa/alexa-avs-sample-app/wiki/Mac#4---generating-self-signed-certificates) and when I was attempting to follow the given instruction:
Edit the ssl.cnf configuration file with your favorite text editor. Replace any placeholder values that start with YOUR_.
Note: countryName must be two characters (e.g. US). If it is not two characters, certificate creation will fail. Additionally, if you will be accessing your device from any IP or DNS entry besides localhost (127.0.0.1 or 10.0.2.2), you must add the additional IP or or DNS entries to [alt_names]. One situation where you will need to add entries to [alt_names] is if you are going to authenticate using an Android or iOS companion app from a device instead of from the Android or iOS emulators on the same machine as the Node.js server and sample app.
I edited the file as said, and not sure if I did do it correctly, but her goes:
[req]
distinguished_name = req_distinguished_name
prompt = no
[v3_req]
subjectAltName = #alt_names
[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1
IP.2 = 10.0.2.2
[req_distinguished_name]
commonName = $ENV::COMMON_NAME # CN= Random
countryName = YOUR_COUNTRY_NAME # C= US
stateOrProvinceName = YOUR_STATE_OR_PROVINCE # ST= CA
localityName = YOUR_CITY # L= San Francisco
organizationName = YOUR_ORGANIZATION # O= VEor
organizationalUnitName = YOUR_ORGANIZATIONAL_UNIT # OU= VE
I also did previously replace the YOUR_ORGANIZATION and etc. with the country codes and etc. themselves, like the following:
[req]
distinguished_name = req_distinguished_name
prompt = no
[v3_req]
subjectAltName = #alt_names
[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1
IP.2 = 10.0.2.2
[req_distinguished_name]
commonName = $ENV::COMMON_NAME # CN= Random
countryName = US # C=
stateOrProvinceName = CA # ST=
localityName = San Francisco # L=
organizationName = VEor # O=
organizationalUnitName = VE
Yet, I still get this output:
❯ ./generate.sh
Generating RSA private key, 4096 bit long modulus
...........................++
.........................................................................................................................................................................................................................................++
e is 65537 (0x10001)
error on line 14 of ssl.cnf
140736175395720:error:0E065068:configuration file routines:STR_COPY:variable has no value:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22/libressl/crypto/conf/conf_def.c:573:line 14
Generating RSA private key, 2048 bit long modulus
...........+++
........+++
e is 65537 (0x10001)
error on line 14 of ssl.cnf
140736175395720:error:0E065068:configuration file routines:STR_COPY:variable has no value:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22/libressl/crypto/conf/conf_def.c:573:line 14
certs/client/client.csr: No such file or directory
Error opening input file certs/client/client.crt
certs/client/client.crt: No such file or directory
Generating RSA private key, 2048 bit long modulus
......................................................................................................................................+++
....+++
e is 65537 (0x10001)
error on line 14 of ssl.cnf
140736175395720:error:0E065068:configuration file routines:STR_COPY:variable has no value:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22/libressl/crypto/conf/conf_def.c:573:line 14
certs/server/node.csr: No such file or directory
Generating RSA private key, 2048 bit long modulus
....+++
...................................+++
e is 65537 (0x10001)
error on line 14 of ssl.cnf
140736175395720:error:0E065068:configuration file routines:STR_COPY:variable has no value:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22/libressl/crypto/conf/conf_def.c:573:line 14
error on line 14 of config file 'ssl.cnf'
Error opening input file certs/server/jetty.crt
certs/server/jetty.crt: No such file or directory
cp: certs/ca/ca.crt: No such file or directory
Error opening Certificate certs/ca/ca.crt
140736175395720:error:02001002:system library:fopen:No such file or directory:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22/libressl/crypto/bio/bss_file.c:255:fopen('certs/ca/ca.crt', 'r')
140736175395720:error:20074002:BIO routines:FILE_CTRL:system lib:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22/libressl/crypto/bio/bss_file.c:257:
unable to load certificate
cp: certs/ca/ca.der: No such file or directory
What should I do differently to ensure it works?

please modify ur openssl directory in generate.sh
->/usr/local/opt/openssl/bin/openssl
https://github.com/alexa/alexa-avs-sample-app/issues/1004

Related

Understanding certificate revocation configuration (crl.cnf/openssl.cnf) file

I have a crl.cnf as below:
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = _CA_dir_
database = _index_fname_ # database index file.
# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
In the above file, What does CA_dir , index_fname and ca_default variables refer to or how to find what values those variables hold? It would be really helpful if someone helps me to understand this. Thanks in advance!

Allow LDAPS service in SLAPD

I created self-signed certificates for my server and the StartTLS under unencrypted port is ok, but I need to operate under the encrypted port too, as Jenkins ldap-plugin is not able to use the StartTLS feature.
I start my server with:
slapd -h "ldap:/// ldaps:///" -f /etc/ldap/slapd.conf -d config -d conns -d packets
If I run this ldapsearch:
ldapsearch -d 1 -v -H "ldaps://[server ip]" -D "[manager dn]" -w [manager password]
I receive this error:
ldap_url_parse_ext(ldaps://172.17.0.1)
ldap_initialize( ldaps://172.17.0.1:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://172.17.0.1:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 172.17.0.1:636
ldap_new_socket: 4
ldap_prepare_socket: 4
ldap_connect_to_host: Trying 172.17.0.1:636
ldap_pvt_connect: fd: 4 tm: -1 async: 0
attempting to connect:
connect errno: 111
ldap_close_socket: 4
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
but if I run openssl to test the connection:
openssl s_client -connect [server ip]:686
I receive that it's ok:
CONNECTED(00000003)
depth=1 C = BR, ST = Sao Paulo, O = example.com, CN = Davi Diorio Mendes, emailAddress = ddiorio#-----.com
verify return:1
depth=0 C = BR, ST = Sao Paulo, L = Campinas, O = example.com, CN = example.com, emailAddress = ddiorio#-----.com
verify return:1
---
Certificate chain
0 s:/C=BR/ST=Sao Paulo/L=Campinas/O=example.com/CN=example.com/emailAddress=ddiorio#-----.com
i:/C=BR/ST=Sao Paulo/O=example.com/CN=Davi Diorio Mendes/emailAddress=ddiorio#-----.com
1 s:/C=BR/ST=Sao Paulo/O=example.com/CN=Davi Diorio Mendes/emailAddress=ddiorio#-----.com
i:/C=BR/ST=Sao Paulo/O=example.com/CN=Davi Diorio Mendes/emailAddress=ddiorio#-----.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID+TCCAuGgAwIBAgIJAOcBkNiAzXUIMA0GCSqGSIb3DQEBCwUAMHcxCzAJBgNV
BAYTAkJSMRIwEAYDVQQIDAlTYW8gUGF1bG8xFDASBgNVBAoMC2V4YW1wbGUuY29t
MRswGQYDVQQDDBJEYXZpIERpb3JpbyBNZW5kZXMxITAfBgkqhkiG9w0BCQEWEmRk
aW9yaW9AYnIuaWJtLmNvbTAeFw0xNjA3MjcxNTUxNDFaFw0xNzA3MjcxNTUxNDFa
MIGDMQswCQYDVQQGEwJCUjESMBAGA1UECAwJU2FvIFBhdWxvMREwDwYDVQQHDAhD
YW1waW5hczEUMBIGA1UECgwLZXhhbXBsZS5jb20xFDASBgNVBAMMC2V4YW1wbGUu
Y29tMSEwHwYJKoZIhvcNAQkBFhJkZGlvcmlvQGJyLmlibS5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDu8RXjY37lP8foIE0QZ9sQYotjRFdKBxeb
483dHf8NzbUTLILNqImzqU+EqBNRNxuHDhBh45/kM24A5dkcjaS5ZqCR/1pOR8bD
ojoeuNqEu/9ga4MWLqrj0rWxQywiBG/O9VzZg3eV7u34oTj3Rx7paohvU8KOFr8/
r9/cXG6QBXKl8Iu8jdo3KtWy7GcN9HOGkJrFwQ6sKbgIKMFpjrV3ByNapTCPJd32
kFY3Hkq2l54iyJGbO3q62HE3/KYKlRPR2uRjOj4YPxU13bvwRAUd1D77xMDEKya6
yj5M+gYGD8PHIn1lBvWOBaa8tzmM2zGk2H6eMoCFgtJAtqAOVIuRAgMBAAGjezB5
MAkGA1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENl
cnRpZmljYXRlMB0GA1UdDgQWBBRXjVcxfJOMwLS70jGjJb8X8xc2IDAfBgNVHSME
GDAWgBQbykbeuV2BDwKARaTYvpZwwKM/jjANBgkqhkiG9w0BAQsFAAOCAQEAgfKs
kFXxY6ZBzcvHU3wwu5kXZo8BYniJ3YZTGGX45JPF9v0yZzAjWAnYR9xJew+Ac1sZ
GrIA1aI1ooEjo1R42JUelo/PnY5rTuveaRvKG+b2H8+LOf0riIkG92byHazmBrK4
PX7ShgdEvK/B3YoDH201RpO8Fjugb31D9j9XcyfmBioKVUcRuxPTlpzOSWeyW8Db
GZ8Gr2Rz7Vxf0/mV25ikvXWHc/e2zNSD/C6bJcRlgaIo/hkoclpJ510oqj+XVcqI
PK/+QABzb9TX2uoMHA+nb7eV3aUzYHya56NAQNhbdfV1gogHFYPFntiE/dJYNM9c
cIWaKjrHXMFfnM2WIg==
-----END CERTIFICATE-----
subject=/C=BR/ST=Sao Paulo/L=Campinas/O=example.com/CN=example.com/emailAddress=ddiorio#-----.com
issuer=/C=BR/ST=Sao Paulo/O=example.com/CN=Davi Diorio Mendes/emailAddress=ddiorio#-----.com
---
No client certificate CA names sent
---
SSL handshake has read 2562 bytes and written 483 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: A57A8114450D576489124B51B0E68EC8C6F59BDDA8BEDF1DD5CA456C878FD66B
Session-ID-ctx:
Master-Key: 90734979FE60577DD24E35B03BBD6F2E57DF457C54BE0B320FD73C384A8F50A1CB783D629F22E060E89C7EB1B7D70FDA
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1469733255
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
This is my slapd.conf:
# slapd.conf - Configuration file for LDAP SLAPD
##########
# Basics #
##########
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel none
modulepath /usr/lib/ldap
moduleload back_hdb
###########
# SSL/TLS #
###########
TLSCACertificateFile /etc/ldap/example.com.cacert.pem
TLSCertificateFile /etc/ldap/example.com.cert.pem
TLSCertificateKeyFile /etc/ldap/example.com.key.pem
##########################
# Database Configuration #
##########################
database hdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw admin
directory /var/local/ldap/database
index objectClass,cn,uid,mail eq
########
# ACLs #
########
access to attrs=userPassword
by anonymous auth
by self write
by * none
access to *
by self write
by * none
and this is my ldap.conf:
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=example,dc=com
URI ldap://localhost
BINDDN cn=Manager,dc=example,dc=com
SIZELIMIT 0
TIMELIMIT 0
#DEREF never
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ldap/example.com.cacert.pem
TLS_REQCERT allow
Does anyone can spot my mistake? Or point me a direction?
Thanks!
I finally solve the question.
I was starting secure slapd at port 686, while the default secure port is 636, so when clients tries to connect to secure port, the port was wrong. I set the secure port to 636, as is the default.
Other error, the server certificate must use the fully qualified domain name at CN field, and I was using example.com just as a test, but it must be the server address. As I don't have a domain name to the server, I used the server IP.

Cassandra nodes cannot see each other when internode encryption is enabled

I had set up a 6-node Cassandra cluster spanning two AWS regions / datacenters (3 in each) and everything was working fine. After getting that much working I attempted to enable internode encryption which I cannot get to work properly, despite reading innumerable documents on the subject and fiddling endlessly.
I don't see any errors or anything out of the ordinary in the logs. I do see the following line in the logs which indicates it has started the encrypted messaging service, as expected:
MessagingService.java:482 - Starting Encrypted Messaging Service on SSL port 7001
I have enabled verbose logging for SSL in cassandra-env.sh, however this does not produce any errors or additional information about SSL internode connections that I can see (update below):
JVM_OPTS="$JVM_OPTS -Djavax.net.debug=ssl"
I can connect to from one node to all the others on the encrypted messaging port 7001 using nc, so there's no firewall issue.
ubuntu#ip-5-6-7-8:~$ nc -v 1.2.3.4 7001
Connection to 1.2.3.4 7001 port [tcp/afs3-callback] succeeded!
I can connect to each node locally using cqlsh (I haven't enabled client-server encryption) and can query the system keyspace, etc.
However, if I run nodetool status I see that the nodes cannot see each other. Only the node that I'm querying the cluster on is present in the list. This was not the case before internode encryption was enabled, they could all see each other just fine then.
ubuntu#ip-5-6-7-8:~$ nodetool status
Datacenter: us-east_A
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 1.2.3.4 144.75 KB 256 ? 992ae1bc-77e4-4ab1-a18f-4db62bb0ce6f 1b
My process was this:
Created a certificate authority for my cluster
Created a keystore and truststore for each node and added my CA certificate chain to both
Generated a key pair and CSR for each node, signed it with my CA, and added the resulting certificate to each node's keystore
Updated each node's configuration as reads below
Restarted all nodes
The server encryption configuration I'm using is this, with the appropriate values in the $variables.
server_encryption_options:
internode_encryption: all
keystore: $keystore_path
keystore_password: $keystore_passwd
truststore: $truststore_path
truststore_password: $truststore_passwd
require_client_auth: true
protocol: TLS
algorithm: SunX509
store_type: JKS
cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
If anybody could offer some insight or a direction to look in it would be greatly appreciated.
Update: Cipher Suite Agreement
Apparently SSL debug logging prints to stdout, which is not logged to Cassandra's logfiles, so I didn't see that output before. Running Cassandra in the foreground I can see a ton of SSL errors tracing out, all of which complain of handshake failure, because:
javax.net.ssl.SSLHandshakeException: no cipher suites in common
In an attempt to solve this problem I have switched to the Oracle JRE (I was being lazy and using OpenJDK before) and installed the JCE unlimited strength cryptography policy files to ensure all possible ciphers would be supported.
It didn't fix anything.
This is especially confusing given that all these nodes are exactly identical: hardware, OS vendor and version, Java vendor and version, Cassandra version, and configuration file. I cannot imagine why they cannot agree on a cipher suite under these circumstances.
The following is the full error that is traced:
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1449074039 bytes = { 205, 93, 27, 38, 184, 219, 250, 8, 232, 46, 117, 84, 69, 53, 225, 16, 27, 31, 3, 7, 203, 16, 133, 156, 137, 231, 238, 39 }
Session ID: {}
Cipher Suites: [TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
%% Initialized: [Session-3, SSL_NULL_WITH_NULL_NULL]
%% Invalidated: [Session-3, SSL_NULL_WITH_NULL_NULL]
ACCEPT-/1.2.3.4, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
ACCEPT-/1.2.3.4, WRITE: TLSv1.2 Alert, length = 2
ACCEPT-/1.2.3.4, called closeSocket()
ACCEPT-/1.2.3.4, handling exception: javax.net.ssl.SSLHandshakeException: no cipher suites in common
ACCEPT-/1.2.3.4, called close()
ACCEPT-/1.2.3.4, called closeInternal(true)
INFO 16:33:59 Waiting for gossip to settle before accepting client requests...
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
ACCEPT-/1.2.3.4, setSoTimeout(10000) called
ACCEPT-/1.2.3.4, READ: SSL v2, contentType = Handshake, translated length = 57
After a great deal more poking and prodding I've finally managed to get this to work. The problem was related to certificates and the keystore.
As a result of these problems the SSL handshake would fail either due to certificate chain problems or cipher suite agreement problems. Cassandra rather unhelpfully discards errors related to SSL and logs nothing.
In any case, I managed to get things working by doing the following:
Ensure that the CA generates node certificates with both client and server key usage attributes. Failing to include one or the other will prevent nodes from authenticating to each other properly. This presents itself as the cipher suite agreement error. If you're using OpenSSL to manage your CA, I've included the -extensions configuration I used below.
Ensure that both the root and any intermediate CA certificates you are using (if you're using an intermediary CA) are imported into both the keystore and truststore.
Ensure that the node certificate imported into the keystore includes the full trust chain from the primary certificate down to the CA root, including any intermediaries – even though you have already imported these CA certificates separately into the keystore. Failing to do this presents itself as an invalid certificate chain errors.
OpenSSL CA Config
Here's my extensions section for dual-role client/server certificates. You can include this in your OpenSSL config file and reference it when signing by specifying -extensions dual_cert.
[ dual_cert ]
# Extensions for dual-role user/server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, server
nsComment = "Client/Server Dual-role Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, serverAuth
Creating a PEM containing the full trust chain
To create a single PEM file which contains the full trust chain for your node certificate, simply cat all the certificate files in reverse order from the node certificate down to the CA root.
cat node1.crt ca-intermediate.crt ca-root.crt > node1-full-chain.crt

openssl :invalid type in 'policy' configuration

I want to have a self-signed SSL Certificate for my local development server. I was following the guide on https://help.ubuntu.com/community/OpenSSL and at the last step where you issue the command to sign the certificate by issuing the following command:
openssl ca -in tempreq.pem -out server_crt.pem
I get the following error: (last line)
Using configuration from /home/user_name/.ssl/caconfig.cnf
Enter pass phrase for /home/user_name/.ssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName :PRINTABLE:'localhost'
stateOrProvinceName :PRINTABLE:'AA'
countryName :PRINTABLE:'ET'
emailAddress :IA5STRING:'user#example.com'
organizationName :PRINTABLE:'Example Inc'
organizationalUnitName:PRINTABLE:'Development'
localhost:invalid type in 'policy' configuration
What can I do to solve it? Just to serve as a back ground, I don't have a domain name for my server, so I just used localhost to be the commanName. Is that the problem?
Thanks for your help.
Copy the policy from /etc/ssl/openssl.cnf to your configuration file
Rebuild all the file from beginning
The policy section is like following:
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

Passing cert and key as der_bin() in Erlang with ssl

I've taken the certificate and key from the PEM file and decoded the base64 to binary and put them into Cert and Key.
Then I have the following code to open a connection.
make_connection(Cert, Key) ->
Options = [{cert, Cert}, {key, Key}, {mode, binary}],
Timeout = 1000,
% {ok, Socket} replaced for debugging...
Socket = ssl:connect(?PUSH_SERVER_HOST, ?PUSH_SERVER_PORT,
Options, Timeout),
Socket.
Calling make_connection(Cert, Key) returns {error, {eoptions, {key, <<...>>}}}.
When I replace Cert and Key with the path to the PEM file, and Options = [{certfile, ... keyfile ...}], it works and creates the SSL socket as intended.
So am I missing anything with the usage of cert and key alone?
Looking at the ssl.erl file from the ssl application, it seems like you are supposed to use a tuple as your Key, rather than the binary:
validate_option(key, {KeyType, Value}) when is_binary(Value),
KeyType == rsa;
KeyType == dsa ->
{KeyType, Value};
Where the type of the key is specified. It seems there's a bug in the documentation for the connect function, where it says that you are supposed to use a binary (der_bin()) as your Key.