I have MQTT (VerneMQ) setup with TLS authentication. Also I have setup frequent pulling
CRL (certificate revocation list) from CA (Private). I am able to revoke the specific client certificate to blocking it from connecting to MQTT.
There is one certificate which is shared & I don't want to revoke but also don't want client to be able to authenticate with MQTT. Following is my configuration
DOCKER_VERNEMQ_ACCEPT_EULA = "yes"
MY_POD_NAME = "vernemq"
DOCKER_VERNEMQ_KUBERNETES_APP_LABEL = "vernemq"
DOCKER_VERNEMQ_LOG__CONSOLE__LEVEL = "debug"
DOCKER_VERNEMQ_KUBERNETES_LABEL_SELECTOR = "app=vernemq"
DOCKER_VERNEMQ_LISTENER__TCP__ALLOWED_PROTOCOL_VERSIONS = "3,4,5"
DOCKER_VERNEMQ_ALLOW_ANONYMOUS = "on"
DOCKER_VERNEMQ_KUBERNETES_INSECURE = "1"
DOCKER_VERNEMQ_MAX_ONLINE_MESSAGES = "-1"
DOCKER_VERNEMQ_MAX_OFFLINE_MESSAGES = "-1"
DOCKER_VERNEMQ_MAX_INFLIGHT_MESSAGES = "0"
DOCKER_VERNEMQ_LISTENER__TCP__DEFAULT = "0.0.0.0:1883"
DOCKER_VERNEMQ_LISTENER__SSL__DEFAULT = "0.0.0.0:8883"
DOCKER_VERNEMQ_LISTENER__WS__DEFAULT = "0.0.0.0:8080"
DOCKER_VERNEMQ_LISTENER__HTTP__METRICS = "0.0.0.0:8888"
DOCKER_VERNEMQ_LISTENER__HTTP__DEFAULT = "0.0.0.0:8888"
DOCKER_VERNEMQ_LISTENER__SSL__REQUIRE_CERTIFICATE = "on"
# DOCKER_VERNEMQ_LISTENER__SSL__USE_IDENTITY_AS_USERNAME = "on"
DOCKER_VERNEMQ_LISTENER__SSL__CAFILE = "/vernemq/cert/ca.crt"
DOCKER_VERNEMQ_LISTENER__SSL__CERTFILE = "/vernemq/cert/server.crt"
DOCKER_VERNEMQ_LISTENER__SSL__KEYFILE = "/vernemq/cert/server.key"
DOCKER_VERNEMQ_LISTENER__SSL__CRLFILE = "/tmp/shared/ca.crl"
DOCKER_VERNEMQ_ALLOW_REGISTER_DURING_NETSPLIT = "on"
DOCKER_VERNEMQ_ALLOW_PUBLISH_DURING_NETSPLIT = "on"
DOCKER_VERNEMQ_ALLOW_SUBSCRIBE_DURING_NETSPLIT = "on"
DOCKER_VERNEMQ_ALLOW_UNSUBSCRIBE_DURING_NETSPLIT = "on"
Any way I can block the specific client certificate ?
I'm not familiar with vernemq's specific options but why not just set up the ACL to block the user represented by that certificate from being able to subscribe or publish to any topics.
Clients would still be able to connect with that shared certificate, but would not be able to receive or publish any messages.
To make this work you would probably have to use the Certificate identity as the User name (but you appear to have commented that out of the env vars you have shown in the question)
Related
django-allauth been used
ACCOUNT_AUTHENTICATION_METHOD = 'email'
ACCOUNT_USERNAME_REQUIRED = True
ACCOUNT_EMAIL_REQUIRED = True
LOGIN_REDIRECT_URL = 'xxx:index'
ACCOUNT_LOGOUT_REDIRECT_URL = 'account_login'
ACCOUNT_LOGOUT_ON_GET = True
ACCOUNT_EMAIL_SUBJECT_PREFIX = ''
ACCOUNT_DEFAULT_HTTP_PROTOCOL = 'https'
ACCOUNT_UNIQUE_EMAIL = True
DEFAULT_FROM_EMAIL = 'tttt#gmail.com'
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
ACCOUNT_EMAIL_VERIFICATION = "mandatory"
I set this in settings.py and I runserver, sign up and then received an email such as
You're receiving this e-mail because user jjjj#gmail.com has given your e-mail address to register an account on example.com.
To confirm this is correct, go to https://eeee.cloud9.us-east-2.amazonaws.com/accounts/confirm-email/4444/
so I go to the link but then I cannot login. Instead, I receive another mail and I got no error message. I am sure that I use ID and password correctly. What should I do?
Cloud 9
Python 3.7.9
Django 2.2.17
django-allauth 0.44.0
When I go to the link in VERIFICATION, I like to login.
This issue was resolved by myself. The order of url in urls.py was wrong.
urlpatterns = [
path('accounts/', include('allauth.urls')),
re_path(r'^accounts/confirm-email/[^/]+/', RedirectView.as_view(pattern_name='timeline:index'), kwargs=None),
]
is a right order.
re_path(r'^accounts/confirm-email/ should come after path('accounts/',
I set up an OpenBSD 7.0 instance on Vultr in order to get a mail server running with Dovecot and OpenSMTPD. I (mostly) followed the instructions here and here and a bit here.
I set it up to use with virtual mail, creating files in '/etc/mail/virtual' and '/etc/mail/credentials' with a single virtual user: 'user#domain.ca::vmail:2000:2000:/var/vmail/domain.ca/user::userdb_mail=maildir:/var/vmail/domain.ca/user'
I created the encrypted password with 'smtpctl encrypt' and pasted it where it should be in the credentials file.
However, running 'doveadm auth login user#domain.ca' fails.
In /var/log/maillog I get:
Jan 25 14:06:58 vultrBSD dovecot: auth-worker(165): conn unix:auth-worker (pid=44111,uid=518): auth-worker<1>: bsdauth(user#domain.ca): unknown user
Jan 25 14:06:58 vultrBSD dovecot: auth: passwd-file(user#domain.ca): Password mismatch
I know the password is correct, and I tried changing it and pasting in a new one that I created with 'smtpctl encrypt', but still the same error. The '/etc/mail/credentials' file is set to 0440 and owned by _smtpd:_dovecot. Even temporarily setting it to 0777 doesn't work.
I can send mail to the server from another account, I see that is shows up in '/var/vmail/domain.ca/user/new' but I am unable to connect my Thunderbird client to the server. Attempting to set up a new mail account in Thunderbird doesn't seem to work, Thunderbird rejects the password (although it does detect the correct protocols and ports, IMAP/SMTP).
Here is the local.conf file in /etc/dovecot:
auth_debug_passwords = yes
auth_mechanisms = plain
first_valid_uid = 2000
first_valid_gid = 2000
mail_location = maildir:/var/vmail/%d/%n
mail_plugin_dir = /usr/local/lib/dovecot
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext imapsieve vnd.dovecot.imapsieve
mbox_write_locks = fcntl
mmap_disable = yes
namespace inbox {
inbox = yes
location =
mailbox Archive {
auto = subscribe
special_use = \Archive
}
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Junk {
auto = subscribe
special_use = \Junk
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
prefix =
}
plugin {
imapsieve_mailbox1_before = file:/usr/local/lib/dovecot/sieve/report-spam.sieve
imapsieve_mailbox1_causes = COPY
imapsieve_mailbox1_name = Junk
imapsieve_mailbox2_before = file:/usr/local/lib/dovecot/sieve/report-ham.sieve
imapsieve_mailbox2_causes = COPY
imapsieve_mailbox2_from = Junk
imapsieve_mailbox2_name = *
sieve = file:~/sieve;active=~/.dovecot.sieve
sieve_global_extensions = +vnd.dovecot.pipe +vnd.dovecot.environment
sieve_pipe_bin_dir = /usr/local/lib/dovecot/sieve
sieve_plugins = sieve_imapsieve sieve_extprograms
}
protocols = imap sieve
service imap-login {
inet_listener imaps {
port = 993
}
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
inet_listener sieve_deprecated {
port = 2000
}
}
ssl_cert = </etc/ssl/domain.ca.fullchain.pem
ssl_key = </etc/ssl/private/domain.ca.key
userdb {
args = username_format=%u /etc/mail/credentials
driver = passwd-file
name =
}
passdb {
args = scheme=CRYPT username_format=%u /etc/mail/credentials
driver = passwd-file
name =
}
protocol imap {
mail_plugins = " imap_sieve"
}
Has anyone else experienced this and know of a fix?
Thanks.
Hashed strings, including passwords, typically use several layers besides the base hashing algorithm. Two different implementations (dovecot vs smtpd) using the same hashing algorithm will output two different hashes given the same input (password.)
This is due to what is called salt and pepper. Salt is a randomly generated string usually based on some user data as the seed. This salt is then inserted into the password in a way dictated by the implementation (dovecot or smtpd) before hashing the password.
Similarly, pepper is a string dictated by the implementation and inserted into the password before hashing. This combination of salting and peppering creates a unique hash per implementation which makes storing passwords safer. This makes it so that a cracker can't easily compare hashes from several sites or programs to crack user passwords and break into all instances of that password simultaneously.
This is why you can't reuse a password hash stored by one program to unlock the same password when used by another program. Even if both programs use identical hashing algorithms.
The fix should be to set up the credentials individually for each program and not reuse each other's hashes.
I installed Grafana on my Azure virtual machine. Now I want to set OAuth.
In defaults.ini I set the
name = my app
enabled = true
allow_sign_up = true
client_id = with my id
client_secret = with my client_secret
scopes = openid email name
auth_url =
token_url =
api_url =
team_ids =
allowed_organizations =
And this not work. Can anyone have some idea where I wrong.
Do not edit defaults.ini!
Use the following link to create or locate grafana.ini or custom.ini depending on your OS:
https://grafana.com/docs/grafana/latest/installation/configuration/
I would recommend that you copy the block of code for the OAuth provider you want to use to grafana.ini/custom.ini and then edit it to suit your need.
You may have to edit the URL under the [server] settings to allow for the correct redirect when using external OAuth
I am getting the below error when trying to use SSO for mattermost with gitlab. How do you enable OAuth2 in Gitlab?
GitLab Mattermost needs your help:
The system admin has turned off OAuth2 Service Provider.
Go back to Mattermost
My /etc/gitlab/gitlab.rb looks like this -
mattermost_external_url 'http://url/'
mattermost['gitlab_enable'] = true
mattermost['gitlab_id'] = "code123"
mattermost['gitlab_secret'] = "code456"
mattermost['gitlab_scope'] = ""
mattermost['gitlab_auth_endpoint'] = "http://url/oauth/authorize"
mattermost['gitlab_token_endpoint'] = "http://url/oauth/token"
mattermost['gitlab_user_api_endpoint'] = "http://url/api/v3/user"
I enabled mattermost['service_enable_oauth_service_provider'] = true, but it gave me a different error. Maybe this is all you need.
This example code fails:
require("socket")
require("ssl")
-- TLS/SSL server parameters
local params = {
mode = "server",
protocol = "sslv23",
key = "./keys/server.key",
certificate = "./keys/server.crt",
cafile = "./keys/server.key",
password = "123456",
verify = {"peer", "fail_if_no_peer_cert"},
options = {"all", "no_sslv2"},
ciphers = "ALL:!ADH:#STRENGTH",
}
local socket = require("socket")
local server = socket.bind("*", 8888)
local client = server:accept()
client:settimeout(10)
-- TLS/SSL initialization
local conn,emsg = ssl.wrap(client, params)
print(emsg)
conn:dohandshake()
--
conn:send("one line\n")
conn:close()
request
https://localhost:8888/
output
error loading CA locations ((null))
lua: a.lua:25: attempt to index local 'conn' (a nil value)
stack traceback:
a.lua:25: in main chunk
[C]: ?
Not very much info. Any idea how to trace down to the problem ?
Update
Got this now: the cafile parameter is not necessary for server mode:
local params = {
mode = "server",
protocol = "sslv23",
key = "./keys/server.key",
certificate = "./keys/server.crt",
password = "123456",
options = {"all", "no_sslv2"},
ciphers = "ALL:!ADH:#STRENGTH",
}
LuaSec is a binding for OpenSSL, so the error you are getting (error loading CA locations) means that the OpenSSL library cannot read your CA files. Are you sure they are in the current directory and with proper permissions?
EDIT: According to LuaSec sources, it currently uses only the PEM format for private key. Ensure that the private key is stored as PEM, not DER.
CAFile contains the set of certificates (.crt) that your server or client trust. You put the key (.key).