I have a version of an application that uses PKI (X509) for authentication/authorization. In an older version of apache (2.2) the DN is delimited by forward slashes (/), in the version of apache (2.4) on my new box the DN for the SAME CERTIFICATE is delimited by commas (,).
What tool does Apache use to parse the DN out of the certificate?
Not sure about the tool/library that Apache uses, but a certificate itself doesn't use delimiters.
The whole certificate is formatted in asn1 which is a tree structure right down to the components of the DN in the subject name field.
The delimiters are very likely only relevant for display purposes.
Related
From SSL2BUY I have the text for a certificate starting with "-----BEGIN CERTIFICATE-----" down to "-----END CERTIFICATE-----". There is no download option just an email option (but that person isn't available) how do I convert the encrypted text between the 'begin' and 'end' statements to an actual certificate?
There are also 4 sections within this page; Servers, PKCS7, Root and Intermediate. How do these all interact?
SSL has been a bane of my life for a long time and I need to conquer this once and for all -_-.
Any assistance will be much appreciated.
I would like to inform you that Servers Certificate and PKCS7 Certificate are different formats of certificate.
PKCS7 format certificate is used in java based server like Tomcat and if you are not using Tomcat you can disregard it.
If you are using a server like IIS, cPanel, Apache etc then you will need to install "Server Certificate". You need to paste the certificate in notepad and save it with .cer extension.
If you are using a windows based server(IIS) then you will need only 1 file to install there which is "server certificate". On Windows based servers, root & intermediate certificates came preinstalled so you can skip that, they are not needed to install again.
If you are servers like Apache, cPanel, Nginx, Plesk, etc then you need to install the main domain certificate and CABundle(combination of the Root and Intermediate certificate).
Please Note:
For all leading CA's (Comodo, Digicert and GlobalSign) all the Root and Intermediate certificates are different. Please suggest your product name so I am able to assist in that particular product which Root and Intermediate certificate has to be used.
Please let me know the server type you are using such as Apache, IIS, cPanel, etc.
For a Java EE 7 web application we are using SSL/TLS client-cert authentication
provided by Wildfly login module.
SSL realm is properly configured with adequate truststore and keystore files on the transport level authentication is successfull, but role mapping cannot map roles as it should based on certificate subject DN for some certificates.
These certificates have cyrillic characters in subject DN which are UTF-8 encoded.
How to configure CertificatesRoles login module to treat rolesProperties file as UTF-8 encoded file?
When I set file.encoding=UTF-8 subject DN from certificate is properly read, but string from roles file is not (i checked twice, it is UTF-8 encoded).
It's a matter of Properties class implementation. This class supports ISO 8859-1 encoding. Solution is to encode UTF-8 encoded file as ISO 8859-1 encoded file by using native2ascii tool provided in Java SDK or JRE.
I'm following this guide to try and install a security certificate on my server: https://docs.bitnami.com/aws/how-to/generate-install-lets-encrypt-ssl/
I want to cover different domain name variants (.com, .co.uk www etc), so am wondering if in this line:
sudo lego --email="EMAIL-ADDRESS" --domains="DOMAIN" --path="/etc/lego" run
I'll be able to use a comma delimited list of domains?
And when I do , will this create a .crt & .key file in /etc/lego/certificates with a really long name? How will it generate the name?
The first domain name that you specify with --domains will be the one granted a certificate and the name used. The extra domain names specified with additional --domains will be part of the SAN (Subject Alternative Names).
SAN allows for multiple domain names to exist in one certificate.
We have a wildcard .pfx file that's of the pkcs 12 convention. We have a vendor that's trying to use it, but it's only working on the whatever.company.com sites (for desktops), and not working on the m.whatever.company.com sites (for mobile). We're assuming this is happening because the wildcard cert is only for *.company.com, and not *.*.company.com.
Do we need to get a new cert created for *.*.company.com or does anyone know of a way to... I don't know... append the additional sub-subdomain to the existing cert? Maybe with keytool and/or OpenSSL .... ?
First, you cannot edit an existing signed certificate without invalidating the signature. And with an invalid signature the certificate will be considered invalid and rejected by the browser. Just imagine if editing a certificate would be possible and the edited certificate accepted by the browser: in this case an attacker could easily modify an existing certificate for its own domain to include any other domain for which he wants to do a man in the middle attack.
Apart from that wildcards like *.*.example.com are not possible, i.e. only a single wildcard is allowed and only in the leftmost label.
I hit a compatibility issues with Oracle Weblogic and an SSL certificate which uses wildcard DNS names in in the Subject Alternate Names (SAN) extension. Seems that none of the modern browsers have a problem with that, but according to Thawte and Oracle for example this is not allowed and Weblogic's wildcard hostname verifier miserably fails - apparently by design:
http://docs.oracle.com/cd/E29542_01/apirefs.1111/e13941/weblogic/security/utils/SSLWLSWildcardHostnameVerifier.html
"DNSNames obtained from the peer certificate's SubjectAlternativeNames extension may not be wildcarded"
Other CAs seem to be perfectly alright with issuing such certs.
RFC 5280 seems to leave implementation in this case up in the air:
"Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics."
With the obvious security considerations aside are there any rules which apply?
PS
Now I can really appreciate having standards...
SAN with wildcards are perfectly valid for HTTPS. RFC5280 ist probably not the right RFC for this stuff since it leaves these details out. Better look at RFC6125 and RFC2818.
But of course wildcards have restrictions. You can only use them in the leftmost label (no *.*.com) and they only match a single label, that is *.example.com matches www.example.com but not www.foo.example.com.