Urgent -- Help with import_from_archive_stream() key/cert management API call

M,

 

 

I'm not one of the Devs, but I've done a bit of work in the KeyCertificate interface and will help if I can. What language are you writing in and what version are you testing this on? Can you please post your code so that I can see it?

 

 

Without seeing your code, I can only make a guess, but it sounds like you might be giving file names when what the interface is looking for is IDs. I've run into that a lot with the KeyCert interface. Whereas the file name might be www.example.com.crt or www.example.com.key, the ID will be www.example.com. The parameter descriptions seem to support that. Whereas I don't think that this would work (I use Perl):

 

 

$soapresponse = $certkey->import_from_archive_stream(

 

SOAP::Data->name (mode => MANAGEMENT_MODE_DEFAULT ),

 

SOAP::Data->name (archive_stream => [blah.tgz] ),

 

SOAP::Data->name (keys => [www.example.com.key] ),

 

SOAP::Data->name (certs => [www.example.com.crt]),

 

);

 

 

I think that this WOULD work:

 

 

$soapresponse = $certkey->import_from_archive_stream(

 

SOAP::Data->name (mode => MANAGEMENT_MODE_DEFAULT ),

 

SOAP::Data->name (archive_stream => [blah.tgz] ),

 

SOAP::Data->name (keys => [www.example.com] ),

 

SOAP::Data->name (certs => [www.example.com]),

 

);

 

 

Hope that this is the answer, but if it's not, we'll just keep working until we get it figured out.

 

 

Chris

M,

 

 

Did my suggestion work for you??

 

 

Just trying to determine whether we need to keep working on this.

 

 

Thanks,

 

 

Chris

Unfortunately, neither identifiers work (the 'base' filename vs. the 'full' filename).

 

 

I've reached out to some folks at F5 directly to see if they can point someone with access to the source code to this thread so they can clarify. The documentation, unfortunately, does little to illuminate how this identifier should be derived. :(

What are you passing in for the archive_stream parameter? It should be a base64 encoded version of the local .tgz file (not on the BIG-IP). The api call uploads the content, stores it in a temporary file (/var/run/tempKMArchive.tgz) and then calls the import_from_archive_file() method with the file path as a parameter.

 

 

You said you already uploaded the .tgz to the BIG-IP. If that's the case, then you'll likely want to use the import_from_archive_file() method where instead of passing in a blob with the .tgz base64 encoded content, you'll pass in the path on the BIG-IP where the .tgz file is located.

 

 

I believe the .Net bindings take care of the base64 encoding for you, but if you are using Perl, then you would do something like this

 

 

$tgz_content = &LoadContentFromFile("c:\temp\foo.tgz") (where LoadContentFromFile loads the content from the file - B-) ).\

 

$tgz_encoded = SOAP::Data->type(base64 => $tgz_content);

 

$soapresponse = $certkey->import_from_archive_stream(

 

SOAP::Data->name (mode => MANAGEMENT_MODE_DEFAULT ),

 

SOAP::Data->name (archive_stream => [$tgz_encoded] ),

 

SOAP::Data->name (keys => ["www.example.com.key"] ),

 

SOAP::Data->name (certs => ["www.example.com.crt"]),

 

);

 

 

or you could just use the import_from_archive_file method if you already have the .tgz in /var/tmp/myarchive.tgz on the BIG-IP.

 

 

$soapresponse = $certkey->import_from_archive_file(

 

SOAP::Data->name (mode => MANAGEMENT_MODE_DEFAULT ),

 

SOAP::Data->name (archive_location => ["/var/tmp"] ),

 

SOAP::Data->name (archive_name => ["myarchive.tgz"] ),

 

SOAP::Data->name (keys => ["www.example.com.key"] ),

 

SOAP::Data->name (certs => ["www.example.com.crt"]),

 

);

 

 

 

Hope this helps...

Hi, Joe. What I was saying is that the TAR stream definitely makes it over to the F5 (using the import_from_archive_stream() API command), not that I manually uploaded it. I do base64 encode the content. It looks like import_from_archive_stream() temporarily places the tar in /var/run/tempssl and untars it. This I can see is succeeding. What doesn't seem to happen is that the actual key/cert is imported into the F5 configuration. I hope that is more clear.

Here's George Watkins's reply on this:

 

 

Here is an unfixed bug that is tracking this behavior: BZ372118 - import_all_from_archive_file and import_all_from_archive_stream doesn't create file objects.

 

 

The key_import_from_pem and certificate_import_from_pem both work correctly in v11 and I've used them extensively without issue. This is likely the method that better than 99% of our iControl customers will use for importing certificates via the API. If they need to upload a tarball of certs and keys, they can do all the extraction, conversion, etc. via native libraries it will just make their code a bit heavier.

 

 

https://devcentral.f5.com/wiki/iControl.Management__KeyCertificate__certificate_import_from_pem.ashx

 

https://devcentral.f5.com/wiki/iControl.Management__KeyCertificate__key_import_from_pem.ashx

 

 

Aaron

Thanks, Aaron. It's good to know this is a bug I am encountering and not simply operator error. I usually presume it's my fault, and then when I get stumped, I came here and beg for help... ;)

 

 

The workaround you mention is indeed how we initially upload certificates/keys to load balancers. But when you need to go replace them, those methods no longer work. The API calls certificate_import_from_pem and key_import_from_pem do have a flag to let you overwrite, but really in practice this does you no good because the load balancer with throw an error telling you the key does not match the cert. Nor can you combine the two calls into a single atomic operation/transaction. Hence my efforts to explore the import_from_archive_stream as a method of updating existing certificates.

 

 

This is actually my ugly hack/work-around for now:

 

 

tmsh_cmd = "echo \"cd /%s; create cli transaction; modify sys file ssl-cert %s.crt source-path %s; modify sys file ssl-key %s.key source-path %s; submit cli transaction\" | tmsh -q" % (partition, identifier, urlpath_cer, identifier, urlpath_key)

 

 

That's basically the command that's constructed and passed via ssh to the load balancer to run remotely. The silly echo thing is because normally tmsh doesn't want to let you invoke transactions via a plain "tmsh" command -- it wants you to actually be in an interactive tmsh session. The echo pipe fakes it out and luckily it all works.

 

 

Ideally, I don't want to be spawning remote ssh commands to perform these actions -- I'd much rather do this 100% through iControl.

 

Thanks, Aaron. It's good to know this is a bug I am encountering and not simply operator error. I usually presume it's my fault, and then when I get stumped, I came here and beg for help... ;)

 

 

The workaround you mention is indeed how we initially upload certificates/keys to load balancers. But when you need to go replace them, those methods no longer work. The API calls certificate_import_from_pem and key_import_from_pem do have a flag to let you overwrite, but really in practice this does you no good because the load balancer with throw an error telling you the key does not match the cert. Nor can you combine the two calls into a single atomic operation/transaction. Hence my efforts to explore the import_from_archive_stream as a method of updating existing certificates.

 

 

This is actually my ugly hack/work-around for now:

 

 

tmsh_cmd = "echo \"cd /%s; create cli transaction; modify sys file ssl-cert %s.crt source-path %s; modify sys file ssl-key %s.key source-path %s; submit cli transaction\" | tmsh -q" % (partition, identifier, urlpath_cer, identifier, urlpath_key)

 

 

That's basically the command that's constructed and passed via ssh to the load balancer to run remotely. The silly echo thing is because normally tmsh doesn't want to let you invoke transactions via a plain "tmsh" command -- it wants you to actually be in an interactive tmsh session. The echo pipe fakes it out and luckily it all works.

 

 

Ideally, I don't want to be spawning remote ssh commands to perform these actions -- I'd much rather do this 100% through iControl.

 

Guys,

 

 

M is correct. If you do a certificate or key upload trying to replace a different cert or key, the operatation will complete (in 11.x), but the cache path attribute will be messed up.

 

 

I haven't yet found a way to deal with this other than M's workaround of doing a CLI transaction.

Hi,

I am trying in java with import_from_archive_stream but the program is getting terminated. The file is not getting copied also and no errors seen.

any help would be very much appreciated.

Path path = Paths.get("C:/ssl/webcertkey.tgz"); byte[] data = Files.readAllBytes(path);

  interfaces.getManagementKeyCertificate().import_from_archive_stream(
                 ManagementKeyCertificateManagementModeType.MANAGEMENT_MODE_DEFAULT, data, keyFileNames,
                 certFileNames);