Based on the below reference link in configuring Haproxy with TLS:
Do i need to have the certificates generated with common SAN(Subject ALternate name) on all the target nodes (or)
Having the individual certs without any common SAN would work ?
https://serversforhackers.com/c/using-ssl-certificates-with-haproxy
Look at https://security.stackexchange.com/questions/172626/chrome-requires-san-names-in-certificate-when-will-other-browsers-ie-follow : some browsers (Chrome) require names to be in the SAN part as they disregard now completely the CN field
So even for a one domain certificate you need the domain both in the CN (as this is not optional) and in the SAN part.
It is also in the CAB Forum requirements, section 7.1.4.2.1 :
Certificate Field: extensions:subjectAltName
Required/Optional: Required
Contents: This extension MUST contain at least one entry.
Each entry MUST be either a dNSName containing the Fully-Qualified
Domain Name or an iPAddress containing the IP address of a server.
The CA MUST confirm that the Applicant controls the Fully-Qualified
Domain Name or IP address or has been granted the right to use it by
the Domain Name Registrant or IP address assignee, as appropriate.
Wildcard FQDNs are permitted.
Note that some other browsers, like Firefox, fallback to the CN instead, see https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 and see beginning of patch at https://hg.mozilla.org/mozilla-central/rev/dc40f46fae48 for the security.pki.name_matching_mode configuration option.
Related
I am trying to access my website using both its domain name and static ip address via https protocol.
When I use just domain it works as expected, but when I add ip address as following:
my.domain.com {
respond "Hello from domain"
}
10.20.30.40 {
tls internal
respond "Hello"
}
it does not work. Moreover if I use tls internal for different port:
my.domain.com {
respond "Hello from domain"
}
:8080 { <----------- Here I use port
tls internal <------------- and tls internal
respond "Hello"
}
accessing by domain name in browser now warns that certs are not publicly trusted. I assume that tls internal in second block affected first block. Is it right? Why so?
Anyway, my main question is how to access my website both via domain name and ip address even if I need to use different ports with caddy over https. I know, that for some historical reason ip addresses cannot have publicly trusted certs so it is ok if ip address will use self signed certs.
pls help!
Caddy version: v2.3.0
I have noticed that when I run fabric ca it start registering affiliation of the organization. But it is converting to lower case of the organization affiliations.
In Fabric-ca-server-config.yaml file below is the affiliations with the name airlineOrg
enter image description here
In the debug logs of fabric ca before starting the restApi server, I see the affiliation name is converting to a lower alphabet as seen below.
enter image description here
The question is, why fabric ca is changing the name of configured affiliation to lower case? because of this, I am unable to create a user.
So, what I did in the rest API server code on getAffiliation method I have changed organization name ex: airlineorg to the lower case of the organization just to test and after that, and it successfully created in the wallet.
When you specify affiliations in the fabric-ca-server-config.yaml file, any non-leaf entry in the config file will be converted to lowercase. This is actually due to a poor design which directly leverages a config library to parse/load the config file. So if your config looks like:
affiliations:
airlineOrg:
someOtherOrg:
then the stored affiliations will be airlineorg and someotherorg and that is what you'll need to specify in your API calls or on the command-line.
If you config looks something like:
affiliations:
airlineOrg:
- Pilots
- Mechanics
someOtherOrg:
then only the non-leaf nodes are converted to lowercase and you access Pilots and Mechanics as airlineorg.Pilots and airlineorg.Mechanics.
I want 4 intermediate CAs for a peer organization: ICA1, ICA2, ICA3 and ICA4 - one for every Node OU (peer, orderer, admin and client).
Let's say if I place ICA1 as the cacerts attribute in the Peer Node OU of the channel configuration, then will a peer identity under a different ICA (ICA2, ICA3 or ICA4), be able to satisfy a policy which says signature of "OrgMSP.peer"?
If yes, then how can I make sure that only the set of roles under a specific department can satisfy a policy given by OrgMSP.<role>? I do not wish to create an MSP definition for every department or team in the organization. So, is it achievable without that?
If no, then can I also specify a group of ICAs in the Node OU configuration of the channel for a particular OU so that I can leverage very complex policies like "Signature of one-of 'OrgMSP.peer'" and let's say that here, cacerts property for the peer OU will be ICA1 and ICA3. Is this achievable?
When you specify the nodeOU configuration, you may simply supply the OU name corresponding to the role (it sounds like this is what you've done), or you may specify the OU name and an issuing certificate. This could be a root CA, or an intermediate CA, but in either case, in order to satisfy that role, the certificate must have both the OU specified and be issued by the specified CA.
Note: Each role/certificate pair informs the MSP of a valid issuer for certificates satisfying a role. So, if you have CA1, CA2, ICA1, and ICA2, you may specify a given role twice, once for CA1 and once for ICA2. Then only certificates (directly) issued by either CA1 or ICA2 may satisfy the role.
If you look in the sample MSP configuration, you can see that certificate may be specified, but is omitted by default.
You can see more details about how this certificate is used in the actual proto documentation.
I create a Node.js app with HTTPS protocol. I followed a tutorial from nodejitsu https://docs.nodejitsu.com/articles/HTTP/servers/how-to-create-a-HTTPS-server/
But when I sent a request to the server, I git the following error:
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html
When I opened from Chrome, I can only access the page after pressing advanced and proceed to the page.
This is what I filled when generating the certificate:
Country Name (2 letter code) [AU]:ID
State or Province Name (full name) [Some-State]:East Java
Locality Name (eg, city) []:[my city name]
Organization Name (eg, company) [Internet Widgits Pty Ltd]:[some string]
Organizational Unit Name (eg, section) []:[some string]
Common Name (e.g. server FQDN or YOUR name) []:[IP address of the server (Azure server) without port and 'https://']
Email Address []:[my personal yahoo email]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:[empty]
An optional company name []:[empty]
The app is hosted on Azure server.
How can I fix it?
You are using a Self-Signed certificate which is causing verification failure. You need to get a signed certificate to remove the validation error.
i want to validate a set of credentials against the domain controller. e.g.:
Username: joel
Password: splotchy
Domain: STACKOVERFLOW
In .NET 3.5 and newer you can use PrincipalContext.ValidateCredentials(username, password).
Otherwise you're in trouble.
Following the code in the Microsoft Knowledge Base article How to validate user credentials on Microsoft operating systems, i get to the point where you call AcceptSecurityContext:
ss = AcceptSecurityContext(
#pAS._hcred, //[in]CredHandle structure
phContext, //[in,out]CtxtHandle structure
#InBuffDesc, //[in]SecBufferDesc structure
0, //[in]context requirement flags
SECURITY_NATIVE_DREP, //[in]target data representation
#pAS._hctxt, //[in,out]CtxtHandle strcture
#OutBuffDesc, //[in,out]SecBufferDesc structure
ContextAttributes, //[out]Context attribute flags
#Lifetime); //[out]Timestamp struture
except that the function fails with:
SEC_E_NO_AUTHENTICATING_AUTHORITY (0x80090311)
The function failed. No authority could be contacted for authentication. This could be due to the following conditions:
The domain name of the authenticating party is incorrect.
The domain is unavailable.
The trust relationship has failed.
This would be a useful error, except that i can validate the same credentials from .NET 3.5 using:
using (PrincipalContext context = new PrincipalContext(ContextType.Domain, domain))
{
valid = context.ValidateCredentials(username, password);
}
What could be happening that allows .NET to validate a set of credentials, while native code cannot?
Update: LogonUser also fails:
LogonUser("joel#stackoverflow.com", null, "splotchy",
LOGON32_LOGON_NETWORK, LOGON32_PROVIDER_WINNT50, out token);
with
1311 - There are currently no logon servers available to service the logon request
Update Two: i've tried both the preferred Negotiate provider, as well as the Windows NT4 legacy "NTLM" provider
String package = "Negotiate"; //"NTLM"
QuerySecurityPackageInfo(package, [out] packageInfo);
...
AcquireCredentialsHandle(
null, //[in] principle
package, //[in] package
SECPKG_CRED_OUTBOUND, //[in] credential use
null, //[in] LogonID
pAuthIdentity, //[in] authData
null, //[in] GetKeyFn, not used and should be null
null, //[in] GetKeyArgument, not used and should be null
credHandle, //[out] CredHandle structure
expires); //[out] expiration TimeStamp structure
I presume that this is to solve the same problem as another question that you posted.
I kind of understand what you are trying to do now. Let me recap what you wrote on another post.
Username Password Domain Machine on domain? Validate as
======== ======== ================= ================== ==============
iboyd pass1 . No Local account
iboyd pass1 (empty) No Local account
iboyd pass1 stackoverflow.com No Domain account
iboyd pass1 . Yes Local account
iboyd pass1 (empty) Yes Domain account
iboyd pass1 stackoverflow.com Yes Domain account
You want to
Authenticate a user from a domain that your machine doesn't trust
Authenticate a user from a domain that your machine trusted
Authenticate a local user
You can achieve the first two cases by doing proper SSPI handshaking with the domain controller. The KB article that you are referring to in another question is doing loop back SSPI handshaking. It's not going to work in case number one because the client machine does not trust the domain that you are authenticating to. That should be why you are seeing SEC_E_NO_AUTHENTICATING_AUTHORITY.
To cut it short, if you want to do exactly the same thing as
PrincipalContext.ValidateCredentials(username, password);
you need to handle the local user differently from the domain user. For domain user, you need to call ldap_bind_s to bind to the domain controller using the given credentials. For local user, you need to use ADsOpenObject to bind to the WinnT://YourComputerName using the given credentials. This is what PrincipalContext.ValidateCredentials doing from what I read in the Reflector.
I don't see there is any equivalent one single native API doing the same thing for you.