I'm running Samba 4.3.11-Ubuntu on Ubuntu 16.04, and I'm unable to get LDAPS (port 636) to work at all.
Samba is running as an Active Directory Domain Controller, and other AD DC fncitonality seems to be fine.
This used to work, but now there's nothing listening on that port. I'm not sure what I did to break it, but it stopped working after I updated my server with a trusted certificate.
Here's what I have for /etc/samba/smb.conf:
# Global parameters
[global]
workgroup = AD
realm = AD.<redacted>.COM
netbios name = SAMBADC
server role = active directory domain controller
dns forwarder = 8.8.8.8
idmap_ldb:use rfc2307 = yes
tls enabled = yes
tls keyfile = tls/ad.<redacted>.com.key
tls certfile = tls/c7535fc6c5e8e557.crt
tls cafile = tls/gd_bundle-g2-g1.crt
ldap server require strong auth = allow_sasl_over_tls
[netlogon]
path = /var/lib/samba/sysvol/ad.<redacted>.com/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
The error I'm getting is:
nitsadmin#sambadc:/etc/samba$ telnet localhost 636
Trying 127.0.0.1...
Trying ::1...
telnet: Unable to connect to remote host: Cannot assign requested address
Anyone have any idea why this might not work? Any idea what Cannot assign requested address means?
Could you please provide a log file which is specified in your smb.conf parameter log file = while you start the samba service?
There could be something wrong with your certificates.
One thing you could try is to switch to autogenerated self-signed certificate and see if it solves the issue. If it does - you have to fix your certificates.
To do this, remove all certificates from tls folder and reconfigure smb.conf:
tls enabled = yes
tls keyfile = tls/key.pem
tls certfile = tls/cert.pem
tls cafile = tls/ca.pem
Then restart samba service and see if it helps.
Related
I am trying to use stunnel to turn a wss connection into a ws connection because wsServer doesn't support wss. The server is running Ubuntu, and the client I'm using is Chrome, if it matters.
This is my stunnel.conf file
foreground = yes
debug = info
output = /var/log/stunnel.log
[wsServer]
cert = /etc/letsencrypt/live/myurl.com/fullchain.pem
key = /etc/letsencrypt/live/myurl.com/privkey.pem
accept = 0.0.0.0:8443
connect = 127.0.0.1:8080
I'm trying to connect to it with a javascript call:
const socket = new WebSocket('wss://myurl.com:8433');
But I consistantly get a connection error:
(index):13 WebSocket connection to 'wss://myurl.com:8433/' failed: (anonymous) # (index):13
Here's what I've checked:
That my port forwarding/system firewalls aren't eating the connection. If I kill stunnel and setup a regular socket listening on either port 8080 or 8433, I can connect to that socket from the client machine.
wsServer accepts non-encrypted traffic, if I instead connect with ws://myurl.com:8080 it works fine
wsServer accepts connections from localhost just fine, which I understand is necessary when stunnel is running on the same machine as the server
Chrome accepts my cert when used for https pages under the same domain, so I don't think I have a cert signing error, but I don't know how to tell if the cert is related to the connection failing
Stunnel does not print any errors when starting up
Nothing gets printed to /var/log/stunnel.log, although the file was created after I added the output field to the .conf file
Any ideas about what else I can try? Is there some reason the cert that works for https wouldn't work with wss?
Do people recommend using ProxyPass through apache and avoiding stunnel altogether?
Not a solution, but a next troubleshooting step. Get yourself openssl and attempt to connect to 8443. This should spit back the certificate information and at least confirm stunnel is presenting the certificate.
openssl s_client -connect myurl.com:8443
It's been awhile since I configured stunnel, but IIRC you can't put a password on your key.
Hello I configured Gitlab server on a VM OL7. I can easily call the http page. but when I use my self-signed ssl certificate generated using the method offered here, I can't call my page and I get a timeout as error. My configuration is simple and I have already tried different variants someone could tell me how I can configure this one. note that I don't want to use let's encrypt for this.
this is an example of my gitlab.rb
external_url 'http://gitlab.icw19.lab'
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.icw19.lab.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.icw19.lab.key"
Your external_url value should include https:// to indicate that you wish to use SSL on port 443. Then GitLab will listen on 443 and will configure Nginx to use your SSL certificates.
external_url 'https://gitlab.icw19.lab'
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.icw19.lab.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.icw19.lab.key"
I try to activate ssl of emqttd server. For this, I added following lines to emq.conf under the etc folder.
mqtt.listener.ssl.tls_versions = tlsv1.2,tlsv1.1,tlsv1
mqtt.listener.ssl.handshake_timeout = 15s
mqtt.listener.ssl.keyfile = etc/certs/key.pem
mqtt.listener.ssl.certfile = etc/certs/cert.pem
mqtt.listener.ssl.cacertfile = etc/certs/cacert.pem
mqtt.listener.ssl.verify = verify_peer
All other settings is same to default.
However, I can connect my local mqtt server without doing any ssl configuration like ssl version, certificate, etc. by using mqtt-spy broker. I think i didn' t configure ssl properties of emqttd. How can i solve this problem?
Thanks in advance.
You must check which port you are trying on for SSL.
Secondly you need to place your key.pem and cert.pem at the path mentioned.
It will just work fine if client have the certificate to authenticate the server.
I'm trying to set up Dovecot with multiple vhosts using SSL.
I've set up my main domain (example.de) and for my vhosts (example2.com & example3.co.uk) I'm using the local -option.
My problem:
When I connect to my server, it complains about a wrong hostname
(example3.co.uk) on my main and other domain for the certificate.
How can I make dovecot use the correct certificate for each host?
Here's my dovecot config:
listen = *
ssl = yes
protocols = imap pop3
disable_plaintext_auth = no
auth_mechanisms = plain login
mail_access_groups = vmail
default_login_user = vmail
first_valid_uid = 2222
first_valid_gid = 2222
#mail_location = maildir:~/Maildir
mail_location = maildir:/home/vmail/%d/%n
passdb {
driver = passwd-file
args = scheme=SHA1 /etc/dovecot/passwd
}
userdb {
driver = static
args = uid=2222 gid=2222 home=/home/vmail/%d/%n allow_all_users=yes
}
service auth {
unix_listener auth-client {
group = postfix
mode = 0660
user = root
}
user = root
}
service imap-login {
process_min_avail = 1
user = vmail
}
ssl_cert = </etc/pki/tls/certs/example.de.crt
ssl_key = </etc/pki/tls/private/example.de.key
local ohmygodpresents.com {
ssl_cert = </etc/pki/tls/certs/example2.com.crt
ssl_key = </etc/pki/tls/private/example2.com.key
}
local ohmygodpresents.co.uk {
ssl_cert = </etc/pki/tls/certs/example3.co.uk.crt
ssl_key = </etc/pki/tls/private/example3.co.uk.key
}
How can I make dovecot use the correct certificate for each host?
Its not Dovecot per se.
The client needs to use TLS 1.0 or above, and it needs to utilize the Server Name Indication (SNI) extension. Otherwise, Dovecot does not know which virtual server the client is attempting to connect to when the channel is being set up.
You can duplicate/test it with OpenSSL s_client. For example, a "good" connection:
openssl s_client -tls1 -starttls smtp -connect mail.example.com:587 -servername mail.example.com
In the above example, Dovecot will know to send the certificate for example.com when the SSL/TLS connection is started. Even though a STARTTLS extension is used in mail, Dovecot does not know the virtual server because the RCPT command has not yet been sent. Because the RCPT command has not been sent, Dovecot does not know the user or his/her domain.
Here's a "bad" connection. Its SSLv3, so it cannot utilize SNI (SNI is a TLS extension):
openssl s_client -ssl3 -starttls smtp -connect mail.example.com:587
Here's another "bad" connection. Its TLS 1.0, but it does not utlize SNI:
openssl s_client -tls1 -starttls smtp -connect mail.example.com:587
You can also duplicate/test/observe with Wireshark. SNI is sent in the plain text as part of the ClientHello. So you will be able to see protocols, cipher suites, extensions like SNI, and other parameters. Everything in SSL/TLS's handshake and key exchange are plain text (some hand waiving). The plain text messages are integrity checked later when the Finished messages are sent.
You can disable SSLv2/SSLv3 and force TLS, and things will work as expected for most clients. However, a client does not have to send the SNI extension. Windows XP clients will be a problem - they utilize TLS 1.0 but omit SNI. So there's really no fix other than using a modern client.
Your other option is to create a "super certificate". That is, use a certificates with all the DNS names that the mail server serves. In your case, use one certificate with SANs of DNS:3und80.de, DNS:ohmygodpresents.co.uk, DNS:example1.com, etc. Every time you add a new domain or remove an existing domain, you will have to get a new certificate.
See https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/
it is not
local domain.com { ...
it is
local_name domain.com { ...
I installed a general RapidSSL certificate on my Ubuntu 12.04 x64 Apache/iRedMail server at Digital Ocean. It verifies fine in the browser and when I use RapidSSL's checker tool.
However, this server is exclusively for mail, and when I set up an account in Mail (Mac OS) or on my iPhone, etc., I have to make a security exception because it gives me the error "This root certificate is not trusted." And it shows the location as being GuangDong, China for some reason.
I spoke with a support person at eNom (where I bought the SSL certificate) and he mentioned that there might be an issue using the root domain instead of a subdomain for mail, and that I may need a wildcard certificate instead. That suggestion makes no logical sense to me.
My general question is: Is there any difference between setting up a mail server with a general SSL certificate on the root domain, as opposed to a mailserver on a subdomain with a wildcard SSL certificate?
Or is something wrong with my Apache configuration, perhaps?
Thanks! :)
Update:
So now I did the following:
in /etc/dovecot/dovecot.conf
changed:
ssl_cert = </etc/ssl/certs/iRedMail_CA.pem
ssl_key = </etc/ssl/private/iRedMail.key
To:
ssl_cert = </etc/ssl/certificate.crt
ssl_key = </etc/ssl/certificate.key
ssl_ca = </etc/ssl/intermediate.crt
Then in /etc/postfix/main.cf
I changed:
smtpd_tls_cert_file = /etc/ssl/certs/iRedMail_CA.pem
smtpd_tls_key_file = /etc/ssl/private/iRedMail.key
To:
smtpd_tls_cert_file = /etc/ssl/certs/certificate.crt
smtpd_tls_key_file = /etc/ssl/certificate.key
smtpd_tls_CAfile = /etc/ssl/intermeidate.crt
Then, I reboot the server. And Apache hangs, get this error:
root#host:~# service apache2 status
Apache2 is NOT running.
root#host:~# service apache2 restart
* Restarting web server apache2
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
...fail!
root#host:~#
So, then I do this:
netstat -ltnp | grep ':80'
result:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1464/apache2
Then I do this:
kill -9 1464
And Apache restarts fine after that, but roundcube won't let me log in and I can't connect to IMAP or SMTP at all.
Dovecot log says:
Nov 07 04:31:43 imap-login: Error: SSL private key file is password protected, but password isn't given
Nov 07 04:31:43 imap-login: Fatal: Couldn't parse private ssl_key
Update Again:
Everything in Dovecot is working great now. Had to do the following, since my certificate is encrypted with a password:
killall dovecot
dovecot -p
Then enter my password.
Now my problem is with Postfix, which isn't working at all. I'm assuming it doesn't like the password protected key.
You need to configure dovecot to use SSL.
You have installed and configured SSL only for apache, IMAP/POP/SMTP connections are not handled by apache.
And no, there is no difference in using a domain and subdomain.
How to setup iRedmail to use SSL