My company's project requires SSL certificates from our internal company domain. Typically what we do with these self-signed certificates is to export a certificate from a web browser (e.g. Chrome), then we import these certificates into a JVM truststore (cacerts) and we reference the path to this truststore when running a maven build. E.g. by passing the following argument:
-Djavax.net.ssl.trustStore=C:/Users/joebloggs/cacerts
Recently I found out that there is also an option for maven to allow self signed certificates if we set the following parameters:
-Dmaven.wagon.http.ssl.insecure=true
-Dmaven.wagon.http.ssl.allowall=true
I haven't asked anyone in my team why they don't use these the parameters above but I'm 100% sure this is related to security.
I would like to know if it is possible to let maven accept self-signed certificated but only from specific domains.
As an example, we have the following repositories:
primary-nexus.JoeBloggsCompany.com
secondary-nexus.JoeBloggsCompany.com
Is there a way for me to accept self-signed certificates only from the company domain (JoeBloggsCompany.com)?
Certificates are assigned to physical entities (persons or hosts). The host behind the domain JoeBloggsCompany.com is most probably the company's WWW-server.
See Maven Wagon HTTP, Features:
maven.wagon.http.ssl.allowall = true/false (false by default), whether to match the server's X.509 certificate against a requested IP/DNS name. If false/unset, a regular server check will be used, which means that the server's IP/DNS must match either the first CN, the Subject field or one of the Subject Alternative Name extension values (in case Subject or SAN type is either dNSName or iPAddress - see RFC 5280 for more details). Otherwise, no such matching will be applied.
Related
I am working in Ec2 instance. I have connected my php files like http://13.57.220.172/phpinsert.php. But it is not secured site. So i want to convert http into https://13.57.220.172.
I have cloudflare ssl. When i try to add ssl certificate. It shows
com.amazonaws.pki.acm.exceptions.external.ValidationException: Provided certificate is not a valid self signed. Please provide either a valid self-signed certificate or certificate chain. Choose Previous button below and fix it.
i have enclose the image with it.
So how can i get the self signed certificate. is there any online tool available.
I think the error message your seeing has to do with this sentence:
If your certificate is signed by a CA, you must include the
certificate chain when you import your certificate.
from https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html.
Since it sounds like you're not yet in "production" mode, I'm guessing you're not particularly attached to your existing certificate, but just want a certificate to be able to do HTTPS on your web server (and don't really care if it's self-signed).
If you want to use AWS Certificate Manager, I think it would be easier to just let them (AWS) issue you a certificate instead of trying to import one from somewhere else. AWS doesn't charge anything for certificates. https://docs.aws.amazon.com/acm/latest/userguide/acm-billing.html
Even if you get the certificate setup in AWS Certificate Manager, that's not going to be installed directly on your EC2 instance, but rather (most likely) on a load balancer in front of your web server, which will add a little complexity to your setup. https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html
If all you want to do is use HTTPS on your web server, Let's Encrypt (also free) is probably a simpler option. If you are using AWS Linux 2, there are instructions for getting a certificate here - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html
Well, add to the points which #jefftrotman has already mentioned.
If your expectation is to just secure your IP address using HTTPS you can achieve that using the below approaches:
A SELF SIGNED certificate that you can create using OpenSSL.
You can also get an SSL certificate from a trust signing authority like (GoDaddy or VeriSign) or Let's encrypt.
The only requirement in the second point is that for getting a certificate from a valid signing authority you need to have a domain name like "myphpapp.com" and then use this domain to get the SSL certificate.
The below details are in case you want to use AWS ACM(Amazon Certificate Manager)
If you prefer ACM, you can get the free Public SSL certificate which you can map to the IP address and your web application will be secured.
If your requirement is to add SSL certificates (like PEM files) to a web server like
NGINX or Apache then you first need to create a Private CA using in ACM and then you using this CA you will be able to create Private SSL certificates. After creating those you can export the files and add those files to the configuration file. (try to use Amazon Linux 2) ec2 image for ease.
I have been managing Let's Encrypt's SSL certificates for a domain.
Now I am moving to Amazon API gateway. I will be using the AWS Certificate Manager to generate HTTPS certificates for the root domain and a bunch of subdomains.
If I make the transfer, what happens to my current HTTPS certificate which is associated with my domain. If browsers suddenly start seeing a new HTTPS certificate for a domain, for which they had been getting a different HTTPS certificate until now, would this be a problem?
Also, once I make the shift, what do I do with my current (manually managed) Let's Encrypt certificate? Is there a way to permanently void it?
Szabolcs Dombi says
You can have multiple valid certificates for the same domain at the
same time. Moving from one certificate issuer to another should not
cause a problem.
Toby Osbourn says
SSL certificates don’t last forever, most of them need to be renewed
on a yearly cycle and occasionally you will want to change the type of
the SSL certificate mid-cycle.
Since you are replacing certificates, I suggest you to back up the ones you have.
Once you have backed up the old certificates, just overwrite the .crt and .key files with your new ones. Then, reload your web server so it knows to look at these new certificates, and you should be good to go.
If it's within your interest to know more about how to Generate SSL certificate using Amazon Certificate Manager (ACM), I suggest Barguzar, A. (July 2018). Building Serverless Python Web Services with Zappa. where one can read a good step by step guide. See an excerpt of it below:
ACM is a service that manages and creates SSL/TSL certificates for
AWS-based services and applications. An ACM certificate works with
multiple domain names and subdomains. You can also use ACM to create a
wildcard SSL.
ACM is strictly linked with AWS Certificate Manager Private
Certificate Authority (ACM PCA). ACM PCA is responsible for validating
the domain authority and issuing the certificate.
You can have multiple valid certificates for the same domain at the same time. Moving from one certificate issuer to another should not cause a problem.
This also means that if you create a new certificate the old one still can be used unless it already expired.
We need an SSL wildcard certificate for our HTTPS servers all belonging to "*.domain.com".
Is it then possible for us to derive server certificates from the ordered wildcard certificate?
Reason: In case when a server should get compromised we have to be able to revoke the certificate for only this one server. All other servers using certificates derived from the same wildcard certificate should keep working.
Is it possible to purchase such a wildcard certificate? Any recommendations?
No, it is simply not possible. You can not change the base domain once you have ordered an SSL Certificate for.
There is two possible solution you can evaluate.
Contact your SSL Certificate Authority and cancel that order (only if your order is under refund policy), ask for the refund and reorder the SSL for the Wildcard domain which you are wishing to secure.
Get a Multi Domain Wildcard SSL Certificate, it will allow you to secure multiple domain and sub-domains.
No, you can't derive other certificates from a purchased SSL certificates. An ability to use certificate to sign other certificates is mainly controlled by a Basic Constraints certificate extension. This extension consist of two components, one of them (isCA attribute) determine whether this certificate can or cannot be used to sign other certificates.
When you purchase SSL certificate, you will get a certificate with isCA = false value in the Basic Constraints certificate extension.
If you want to control each server's certificate revocation, you have to purchase a separate certificate for each server (either, wildcard or for specific host names).
When an application optionally allows you to specify a certificate which represents a certificate authority, what is that doing?
Does that basically set that cert as a "trusted" certificate?
Specific example:
Kibana communicates with elasticsearch. When you configure kibana, you can set the following configuration value:
elasticsearch.ssl.ca
The documentation says this value is an "Optional setting that enables you to specify a path to the PEM file for the certificate authority for your Elasticsearch instance." (source)
Within that same config you're also specifying a certificate and key that can be used for communication with the elasticsearch instance.
If the setting is optional it means that the default behaviour is to use the system Root CAs to validate the SSL Server certificate used by your Elasticsearch instance. If you used a standard commercial SSL Server certificate this should be enough.
Yes, you are setting that certificate as a Root CA but only for this application.
Using the setting you can specify the Root CA used to generated the SSL Server certificate. This is useful if you:
use a selfsigned certificate
use a Root CA that is not available in the system Root CA repository
need to have stringent security settings limiting subset of Root CAs trusted by your application.
Is it different from any other certificate I can generate via makecert or buy from some authority?
As mentioned by Mile L and Boot to the Head the Extended Key Usage is what determines the purpose that the key can be used for.
Most commercial certificate authorities (Verisign et al) issue certificates for single purposes, or for as few as possible.
They use this narrowing of the puropse to carve out different markets for the certificates and then price them accordingly.
You see them selling different Object Signing certs for Windows Assemblies / Java / Office / Adobe Air etc when (in most cases) the resulting certificate is the same.
For example the Comodo codesigning cert issued here can sign Java applets, WebStart applications, Firefox extensions and even Windows assemblies.
The certificate that's used to sign software is the same certificate that would be used to sign any document. What's different about signing software is where the signature finally resides. In a typical document signing, the signature just gets appended to the original document. You cannot append a signature to most types of software for obvious reasons (some interpreted languages would allow this, but I don't know if it's done in practice).
The solutions to the signature problem vary based on the execution environment. For an executable binary, the signature is often stored in a separate file. In Java you can have a signature embedded in an executable JAR file.
Microsoft has a good reference for an introduction to the signing process.
It depends on what you are doing with it. If you want the certificate to be accepted by a browser in an SSL communication, then it must have a root certificate installed in the browser. The certificates generated by authorities already have their root certs installed in browsers.
If you are using the cert just to sign an assembly, then you don't need it. It depends on who is checking the cert and whether they care if the root is a known authority.
More here:
http://en.wikipedia.org/wiki/Root_certificate
To my knowledge, certificates have a "key usage" attribute that describes what uses the cert is intended for: SSL server, code signing, e-mail signing, etc. So I think it's up to the OS, or web browser, or e-mail client, to check these bits.
When a cert is called into action, the role it purports to perform is as important as identification. It's not just about identity, but also about role authorization. An email protection cert should not be able to perform server authentication. Security concerns dictate a necessary restriction in the power given through a single certificate. The underlying API should enforce the correct usage, be it through the OS or an abstraction such as the .NET Framework.
There are different certificate types because there are very different roles in authentication and authorization that would need them. Allowing different certificate types and hierarchies allow for a model of certificate chains, as found in the "Certification Path" on a certificate. A Server Authentication cert will need to have a top-level CA cert somewhere in the trusted root certificates... or be a part of a family tree of certs which ultimately does. 3rd party Certificate Authorities, I'm sure, price them on a scale of functionality and trust.
Boot To The Head is right... there is an Enhanced Key Usage attribute which provides a description of what the cert claims the role to be (e.g. Server Authentication; or in the case of my CA's cert: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing). Look at the details in a certificate's properties and you'll find it.
I'd also add that a .NET assembly has to be strongly named (which requires it to be signed) in order to be added to the GAC.
There are different types of certs... from the CA that is bundled in Win 2003 server, you can request:
Client authentication
Email protection
Server authentication
Code signing
Time stamp signing
IPSec
Other