I want to configure openssl client-server to support TLS extensions specifically server name indication (SNI).
I have build the latest openssl 1.0.0e on ubuntu linux without giving any additional config parameter.
./config
make
make install
Not sure if I need to give any additional config parameters while building for this version.
Now I have set up server and connecting to it through openssl client using the standard command line tool provided by openssl, viz s_client and s_server.
My question is: how do I specify the host name to be sent as extension in s_client? Does openssl have the provision to specify server name using some parameter in commandline?
Thanks!
This has been lying dormant for some time. Since I figured this out long back, it would be logical to write the answer and put a closure to this.
The command-line option servername is available to specify SNI.
openssl s_client -connect myweb.address.com:443 -servername myweb.address.com
The above command will trigger TLS client with the given server name present in SNI extension of client hello.
For using s_server you can use the command:
openssl s_server -accept 443 -cert normal_cert.pem -key normal_key.ky -servername xyz.com -cert2 sni_cert.pem -key2 sni_key.ky
Here whenever the client will request the server without servername extension the server will reply with normal_cert and if there is servername extension is client hello then server will reply with the sni_cert.
For using s_client with SNI you can use the command:
openssl s_client -servername xyz.com -connect ip:port
The relevant commandline options are:
starttls prot: use the STARTTLS command before starting TLS for those protocols that support it, where 'prot' defines which one to assume. Currently only "smtp", "pop3", "imap", "ftp" and "xmpp" are supported.
servername host: Set TLS extension servername
Related
When trying to connect, an error appears: " i'm trying to parse 'path/openvpn.ovpn' as an --option parameter but i don't see a leading '--' ". How do fix this?
I tried to upgrade to an older version (i have 2.6 installed) and it didn't help.
My client config:
client
dev tun
proto udp
remote ip port
resolv-retry infinite
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name crypt_j619a9d0-68d3-42x0-8d76-82e6bbe654bf name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
First, thanks to all who may or may not try to help me.
My Problem: I'm trying to create an ssl certificate with Let's Encrypt. Already installed everything mentioned in the documentation. I decided to use certbot / since it seemed to be the easiest way for me to fulfill my needs.
We have freed both ports 80 and 443 and every request that comes to one of these ports are redirected to my Ubuntu 18.04 machine's internal IP address.
There are no configurations on this machine, so nothing listens on port 80 or 443, as you can see on my netstat command:
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 895/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1211/sshd
tcp6 0 0 :::22 :::* LISTEN 1211/sshd
After creating the certificate I'll run a spring boot application, which should use the certificate.
As far as I understood from the documentation, it isn't required to have running applications listening on these ports. It ought be possible to create the certificate by using the standalone parameter. So I guess certbot creates a small application listening to one of these ports on it's own to verify that I'm the one, who I claim to be. Right?
placeholder.example.com is as you will assume a placeholder. I think it's obvious why I'm not publishing my domainname, when having port 80 & 443 opened.
root#urlaub:/# certbot certonly --standalone --preferred-challenges http -d placeholder.example.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for placeholder.example.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. placeholder.example.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://placeholder.example.com/.well-known/acme-challenge/jCJ4waxV0aYPxjqDI3OcBXXPReNSrse1kd6piK9Dwdo: Connection refused
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: placeholder.example.com
Type: connection
Detail: Fetching
http://placeholder.example.com/.well-known/acme-challenge/jCJ4waxV0aYPxjqDI3OcBXXPReNSrse1kd6piK9Dwdo:
Connection refused
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
EDIT: I've had tried this a lot of times, without success. Now there are 13 .pem files in /etc/letsencrypt/keys
Can I convert them to .p12 file to use it in an spring boot application?
It was an issue with the redirection to my server machine. So the above used command works properly and I was able to create a certificate. If anyone wants to use it: go for it.
My intent was to use it in a spring boot application and needed a pkcs12 file. I was able to convert the .pem files created by certbot to a .p12 file by using following command:
openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out keystore.p12 -name tomcat -CAfile chain.pem -caname tomcat
In your application.properties you've to put following:
server.port: PORTNUMBER
server.ssl.key-store:/etc/letsencrypt/live/<YOURDOMAIN>/keystore.p12
server.ssl.key-store-password: <PASSWORD YOU WERE PROMPTED WHEN CREATING THE CERTIFICATE>
server.ssl.keyStoreType: PKCS12
server.ssl.keyAlias: tomcat
With Let's Encrypt if you use HTTP validation, you will need a server serving requests on port 80 (HTTP) for placeholder.mydomain.com so that the Let's Encrypt server can download the file .well-known/acme-challenge/jCJ4waxV0aYPxjqDI3OcBXXPReNSrse1kd6piK9Dwdo. This is how Let's Encrypt validates that you have control over the domain. Note: That filename is generated dynamically and will be different each time you attempt validation.
Another option that I use is to use DNS validation and then create the special record in my DNS server. You can then create the certificates on your desktop for any service that requires SSL for that domain name.
I am trying to setup proxy in /etc/yum.conf with https and ssl cert
Normally, i would have proxy=http://x.x.x.x:80 provided that is the proxy address and since my proxy does not require username and password, that would work. But now i have a requirement, to setup /etc/yum/conf with
proxy=https://x.x.x.x:433
and the yum hosting centos can only talk to internet via a proxy which accepts ssl cert based Authentication.
So how would i install the ssl Cert on the centos host for yum to work with the proxy host on port 443 and one that requires an SSL Cert
It looks like you should be able to use the following config directives taken from the yum.conf manual page.
sslclientcert
Path to the SSL client certificate yum should use to connect to
repos/remote sites Defaults to none. Note that if you are using curl
compiled against NSS (default in Fedora/RHEL), curl treats
sslclientcert values with the same basename as identical. This
version of yum will check that this isn't true and output an error
when the repositories "foo" and "bar" violate this, like so:
sslclientcert basename shared between foo and bar
sslclientkey
Path to the SSL client key yum should use to connect to repos/remote
sites Defaults to none.
I've been setting up couchdb to run on SSL following the instructions from couch docs. Its pretty straight forward, you make 3 adjustments to local.ini:
httpsd = {chttpd, start_link, [https]}
cert_file = absolute/path/to/cert.pem
key_file = absolute/path/to/key.pem
I've made the key and certificate with openssl no problem, but whenever I ping port 6984 on the localhost (the port its supposed to run on by default) I just get a non active port:
==> curl https://127.0.0.1:6984/
curl: (7) Failed to connect to 127.0.0.1 port 6984: Connection refused
I've inspected the port, nothing is running there. I can put a node.js server on the port and it works fine too. I can't find a similar situation to this anywhere. I'm running the mac OSX couchdb application (v 2.1.2). It appears that the ssl server daemon is just straight up not running at all. Everything else in couch is working fine. Maybe I have to tweak the local.ini file to turn the daemon on? No idea really. Any suggestions are appreciated.
Not sure if this will ever be a very popular question but just thought I'd point out that a very popular way to set up SSL with couchdb is to use a proxy like haproxy due to annoyances with ssl and erlang (which couchdb is written in).
That being said, I solved my problem by setting up SSL termination at haproxy that then forwards traffic to couchdb on an internal port. For use on a mac OSX machine the steps were pretty easy.
1) Install haproxy with brew brew install haproxy
2) Create a self signed certificate with openssl that haproxy needs for ssl configuration (it's really just a concatenated file of your key and certificate):
openssl genrsa -out key.key 1024
openssl req -new -key key.key -out cert.csr
openssl x509 -req -days 365 -in cert.csr -signkey key.key -out certificate.crt
cat ./certificate.crt ./key.key | tee combined.pem
3) create haproxy configuration file (haproxy.cfg), this is just a pretty naive first implementation, but is a good starting point. Note that "/absolute/path/to/combined.pem" would be changed to wherever the combined.pem file is actually located.
global
maxconn 512
spread-checks 5
defaults
mode http
log global
monitor-uri /_haproxy_health_check
option log-health-checks
option httplog
balance roundrobin
option forwardfor
option redispatch
retries 4
option http-server-close
timeout client 150000
timeout server 3600000
timeout connect 500
stats enable
stats uri /_haproxy_stats
# stats auth admin:admin # Uncomment for basic auth
frontend http-in
# bind *:$HAPROXY_PORT
bind *:443 ssl crt /absolute/path/to/combined.pem no-tls-tickets ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:!MD5:!aNULL:!DH:!RC4
#Add these lines beneath bind, still within http-in
reqadd X-Forwarded-Proto:\ https
# Distinguish between secure and insecure requests
acl secure dst_port eq 8000
# Mark all cookies as secure if sent over SSL
rsprep ^Set-Cookie:\ (.*) Set-Cookie:\ \1;\ Secure if secure
# Add the HSTS header with a 1 year max-age
rspadd Strict-Transport-Security:\ max-age=31536000 if secure
# Redirect HTTP to HTTPS
redirect scheme https code 301 if !{ ssl_fc }
default_backend couchdbs
backend couchdbs
option httpchk GET /_up
http-check disable-on-404
server couchdb1 127.0.0.1:5984 check inter 5s
4) Run couchdb, run haproxy via changing directory to the directory housing the above haproxy.cfg file and running with that configuration: haproxy -f haproxy.cfg.
This is a simple point to start from. This set up can handle load balancing of multiple couchdbs, and in production would need a valid certificate from some authority. For anyone interested in, or having difficulty with ssl and couchdb in a mac OSX development environment, this is a decent solution that I found to work quite nicely.
I'm trying to run MQTT broker (Mosquitto) with TLS support, I followed http://rockingdlabs.dunmire.org/exercises-experiments/ssl-client-certs-to-secure-mqtt to generate certificates and configuration. If I run
sudo /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf -d -v
It throws error in /var/log/mosquitto/mosquitto.log
mosquitto version 1.4.8 (build date Fri, 19 Feb 2016 12:03:16 +0100) starting
Config loaded from /etc/mosquitto/mosquitto.conf.
Opening ipv4 listen socket on port 8883.
Opening ipv6 listen socket on port 8883.
Error: Unable to load server key file "/etc/mosquitto/certs/mqtt_server.key". Check keyfile.
Here is my configuration in conf.d/mymqtt.conf
# MQTT over TLS/SSL
listener 8883
cafile /etc/mosquitto/ca_certificates/mqtt_ca.crt
certfile /etc/mosquitto/certs/mqtt_server.crt
keyfile /etc/mosquitto/certs/mqtt_server.key
require_certificate true
tls_version tlsv1.2
user mosquitto
And these certificate and key files are present in proper location
And here is the content of default mosquitto.conf
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
I ran into the same issue once and it was because the key was password protected. I changed the file settings so that the key file was readable only by a specific set of users and removed the password.
For posterity:
You get this error if the key doesn't match the certificate also. So remember to check that:
openssl rsa -noout -in -key.pem -modulus | openssl md5
should match
openssl x509 -noout -in cert.pem -modulus | openssl md5
I spent hours trying to fix this until I realised I'd mixed up the keys.