Exchange-Certificates
Which certificate do I have to add to my (Docker) Gitlab-Server so I can send mails?
Or do I have make a self-signed-certificate?
gitlab_rails['smtp_ca_file'] = '/path/to/your/cacert.pem'
I think you're misunderstanding the purpose of this setting. gitlab_rails['smtp_ca_file'] is used to help ensure that GitLab properly trusts your SMTP server (which is not provided by GitLab/Omnibus!). This is necessary, for example, in a situation where you may have a SMTP server which utilizes a (potentially self-signed) certificate that is not otherwise trusted under a well-known/trusted CA.
In this context, it would not make sense to generate a certificate -- the certificate should be provided to you by another entity, such as your company mail server or a company Certificate Authority (CA). See this question for details on how you can find the certificate you need using the openssl command (if you can't retrieve it directly from your server configuration or otherwise get it from some other source).
If your mail server uses a certificate issued by a well-known/trusted CA, this setting is not needed.
Related
I am implementing mutual authentication between a single client hosted app (CLIENT) and my spring boot 2 application (SERVER). I understand the steps to be as follows:
The server generates a keystore and truststore. The keystore being used for storing the server's certificates and private key. The truststore used for storing other credentials (certificates from certificate authority (CA) or trusted client certificates).
A CSR is raised for the server which is then passed to a CA. The CA generates a signed certificate from the CSR. This is the installed in the server keystore.
The client (which has it's own keystore and truststore) provides their public key to the server. This is then installed in the server truststore.
When a https request is made from client to server:
The client makes a request to access a protected resource.
Server responds with their public certificate.
Client verifies that certificate (looks in truststore and checks if it signed by a trusted CA).
Client presents their public certificate to server.
Server then verifies certificate against their truststore.
Assuming verification success client is granted access to the protected resource.
So I have a few things which I'm a bit confused about...
Are the steps outlined above broadly correct?
How does the server verify the client certificate? (I think it looks at the truststore for that certificate but not sure what actually happens after that).
I've seen examples of the CA certificate being installed in the server truststore instead of the actual client's public certificate ~ is there a use case when this should or should not be done? For my use case I have been provided with a signed certificate from the client (third party). The CA who signed that is different from the CA who signed the server certificate.
Does this process actually authenticate the client i.e. this client can now have access to the servers protected resources but another client who might present a different certificate will not have access? (like a more secure method of providing a username and password)
Where does common name (CN) checking come into all of this? I note in Spring Boot X.509 you can derive a username from the CN and then use this to lookup the appropriate user details from the user details service.
If the client certificate gets compromised for whatever reasons is this managed by just removing it from the server's truststore?
Is there an advantage, in my scenario of using a trusted CA e.g. verisign to produce a client certificate over a self-signed one? i.e. the certificate is passed to me directly from the trusted third party, and then installed.
In respect to your first question, yes your outlined steps are correct! Here is the general mutualSSL flow with a graphical overview: (source)
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
Your second question (How does the server verify the clients certificate?):
The server verifies the clients certificate with the help of the signature. The signature is usually a hash-value, build of the complete certificate. The hash-value is signed with the private key of a corresponding CA (certificate authority). The server verifies the signature of the client certificate with the help of the CA's public certificate.
Your third question (Servers truststore containing the clients public key/certificate or the corresponding CA certificate?):
If you use for example self-signed certificates, you probably have to import the clients public key/certificate directly into the servers truststore. If your client uses an CA signed certificate, it is appropriate for you server to store the CA public key/certificate only, because it is used to verify the clients certificate.
Your fourth question (Does this process actually authenticate the client): Yes! As you can see in the answer to your second question, the certificate is verified by checking the signature. The signature is a hash over the complete certificate. A standard X.509 contains information to identify the subject. By checking the signature the subject is authenticated. A standard X.509 certificate contains amongst other things e.g. this information:
Subject name, Subject Public Key Info, Public Key Algorithm, Issuer Unique Identifier (optional), ...
Your fifth question (Where comes CN checking?): The CN (common name) verification is executed during the certificate check. The CN identifies the valid hostname for the current certificate. It is limited to one entry. As an extension the SAN (subject alternative name) was introduced. A certificate can contain more than one SAN. The CN (and the SAN) entry is part of the certificate and is verified with the help of the certificates signature check.
Your sixth question (If the client certificate gets compromised for whatever reasons is this managed by just removing it from the server's truststore?): Therefore the CAs use so called revocation lists. If you are using for example self-signed certificates it would also be okay to just remove the compromised certificate entry from the servers truststore.
Your seventh question (Is there an advantage, in my scenario of using a trusted CA e.g. verisign to produce a client certificate over a self-signed one?): There exist a few advantages of using a CA signed certificate instead of self-signed ones.
The certificate and eventually the revocation is managed by the CA
The certificate is valid to every relying party of the public CA, e.g. Verisign
Most of the public CAs offer standardized ways of creating a certificate
I get the following error message.
You have asked Firefox to connect securely to www.gstatic.com, but we can't confirm that your connection is secure.
Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
What Should I Do?
If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.
This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate.
www.gstatic.com uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.
(Error code: sec_error_unknown_issuer)
Can someone please help me to solve this issue :'(
You're receiving this error message because the certificate for the site isn't valid. In order to communicate using SSL with a site, the site must provide a valid certificate. There are a number of things necessary for a valid certificate, but one factor is the certificate must be issued by a trusted certificate authority, or CA. Your browser is preconfigured with a set of trusted CAs, but for this particular site, the issuer is not part of that set of trusted authorities.
Furthermore, since the site is using HSTS (HTTP Strict Transport Security), an exception cannot be made for this certificate.
You'll need to view the certificate and see who issued the certificate (the CA) and whether that is a real CA. The certificate may be self-signed, which means the site issued their own certificate without a trusted CA. If you wish to continue, you'll have to install the issuer's certificate as a trusted CA in your browser. However, do not install the issuer's certificate if you cannot verify their identity as a trusted CA.
This article on your particular error may provide guidance on why you're seeing this message. Here's a general description on how SSL works and what roles certificates and CAs play.
With regard to the first solution, if you end up having to install a CA cert into your Firefox browser, click Edit Trust and check the "This certificate can identify websites" checkbox. If that checkbox is not checked, then Firefox will still not trust websites who issue certificates signed by that CA.
How does the client ensure the ssl certificate that the server send is the true owner of the certificate? How does it prevent a hacker from cloning, for example, the google ssl certificate, and trick me that he is the google site during the handshaking? can the hacker clone the certificate and modify the domain or ip info from network packet to trick people?
An SSL certificate for e.g. www.google.com is signed by a 3rd party named a Certificate Authority (CA). In the case of google that 3rd party is currently "GeoTrust Global CA". Too look up who it is, you need to inspect the certificate (browsers typically will let you do that rather easily, but each has their own way)
That links the certificate with the name "www.google.com".
Your client(s) have a list of CAs they trust on your behalf. That list is either maintained by the vendor of your OS and/or by the creator of your client/browser.
So how does the client know it's talking to the right server ?
The certificate is signed by a CA it trusts, the certificate is for the name the client wants to connect to, and the server delivered proof it knows the corresponding secret key to the public key that's in the certificate.
A hacker who would copy a valid certificate from www.google.com and place it on their own machine would only have the public key and not have the private key.
A hacker who would try to get their certificate request signed by a reputable CA would get rejected because they cannot proof to own the google.com domain. And hence the name would not match.
A hacker who would sign their own certificate request, would fail as their self-built CA is not in the trusted list.
A hacker who would break into google's servers and copy the secret key somehow, could pass muster for a while, but once the folks at Google detect it, they would contact their CA and revoke the certificate.
Now this process is the weak point in most implementations as these revoked certificates are published by the CA as Certificate Revocation Lists (CRLs) or as an OCSP (Online Certificate Status Protocol) service, but clients typically take the shortcut and do not validate that a certificate has not been revoked.
I have created my SSL certificate using Selssl7.exe on server1 but used Cn as Server2 and hosted the certificate on server2. I started to get a certificate error when browsing from linux firefox saying:
This certificate is invalid, the certificate is not trusted and is self signed, the certificate is only valid for server1
But when I browse the URL from Windows IE I just get the regular error saying that it's not trusted and I can easily add it to exceptions.
Can we use self-signed certificates generated on server1 on a different servers?
You can and you may but you are pretty much undermining each and every aspect of authenticity by doing so.
A self-signed certificate is generally a problem because other users will not know this certificate in advance. So their browser dutifully issues a warning. That's why you have to pay for TLS certificates that will be recognized - they are issued by CAs whose certificates are contained in the default trust store of your browser. CAs had to pay to "be part of the club", but otherwise, anyone can create certificates. It's just the matter of being recognized by default settings.
But you open another hole by reusing a certificate that was issued for a dedicated server on a different server. TLS certificates' subject distinguished names must match the host name of the server they are deployed on. This is mandated by the TLS spec because this is the only effective measure to prevent man-in-the-middle attacks when using TLS. After you open a TLS connection to a server, your code will check whether the host name that you are connected to matches the subject DN of the server's certificate that was sent. Only if it does you can be sure to be talking to the right server.
So, in conclusion, if you reuse a server certificate on a different host, then you are severely impacting the security of TLS. It's still possible, sure, but if you cripple security to this extent, then you are probably better off using plain HTTP in the first place.
I issued a self signed certificate on IIS 7.5, and it is working correctly if i access my website through my computer.
However, if i access the website from another computer, i get an warning saying the certificate was issued to another address.
Is this because the certificate was issued to localhost instead of the actual IP?
Or this doesn't make any sense?
Regards,
The error message you are getting is normal, assuming you do not have anything in your certificate aside from 'localhost' to identify the owner.
Your browser is performing a name check, and looking to validate the certificate that is presented with the URL you typed in. Typically, the common name of a certificate matches the hostname/DNS name of the machine. Alternatively, there can be information inside of the Subject Alt Name (SAN) extension of your certificate. There, you could specify multiple DNS names or IPAddress fields that identify your server in addition to the CN.
If you are simply performing internal testing, I would not be terribly worried about the warning you are receiving. Just keep all of this in mind when you move to production. Also, having your CA being self-signed, you may also receive trust warnings, unless you manually import your self-signed CA certificate into the trust store of the browser you are using.
Maybe this helps you: Self signed certificates on IIS 7. At the end of the article, in the section named "Adding the Certificate to Trusted Root Certificate Authorities", an alternative solution is shown, but it implies importing the certificate in the client machine, so that could be a huge disadvantage. However, it is a solution if you can't register the certificate on a Certificate Authority, an you have access to the client machine.